Verwijderen nutteloze AND en 3dShapes tags

Marc, als je in JOSM via Windows de command stack opent kun je exact zien wat je doet. Als je in de selectie obv CTRL-F ontdoet van de twee betreffende tags zie je dat keurig in de command stack terug. Daarna kun je uploaden.

Cheers, Johan

ps als je ooit eens een keer merkt dat een upload niet goed is gegaan kun je dat het beste herstellen door de betreffende changeset(s) te reverten

Niet alles gaat foutloos bij het verwijderen van die overbodige AND tags.

http://overpass-turbo.eu/s/6eD

In de omgeving van Berkel-Enschot levert een aantal landuse=residential gebieden op die wel heel erg raar liggen!
Ongeveer een maand geleden uitgevoerd door it’s so funny_mechanical.

Dit bv:

http://www.openstreetmap.org/way/6333546#map=16/51.5902/5.1338

Wat moeten we daarmee? Opruimen als we ze tegenkomen?

(Ik heb Johan ook een DM gestuurd).

Die shape is gewoon nog van de originele AND import. Alle nodes zijn nog onaangetast, kijk maar op http://osm.mapki.com/history/way.php?id=6333546
Kenmerkend voor die import is dat ze er soms maar met de pet naar hebben gegooid bij het intekenen, weg ermee dus.

Dank voor die geruststelling. Ik ga puinruimen… :slight_smile:

Wellicht ook nog even de node http://www.openstreetmap.org/node/43147954 van het buurtschap loskoppelen van de weg.
Dit ter voorkoming dat de informatie verloren gaat als iemand aan de weg gaan sleutelen.

Vraaf me af of we buurtschappen willen taggen als node of area. Area geeft meer informatie tot waar het zich uitstrekt (zoals de inmiddels verwijderde http://www.openstreetmap.org/way/6333546 aangaf). Aan de andere kant, gewone plaatsen hebben doorgaans ook slechts een enkele node, maar doorgaans wel een of meerdere landuse areas die aangeven wat bebouwd gebied of industrieterrein is.
Denk zelf dat de verwijderde landuse=residential best had kunnen blijven om het gebied van “De Kraan” aan te geven.

Daar zal ik inderdaad naar kijken. Had me niet gerealiseerd dat die node aan de weg vastzat.

Ik heb hem voor mezelf nog even teruggedraaid om te zien wat er verloren was gegaan, maar die landuse area raakte echt “kant noch wal” en omvatte in iedergeval lang niet het hele buurtschap De Kraan.

Kun jijzelf ook terugdraaien om te zien of ik gelijk heb? Het ging om deze changeset:
http://www.openstreetmap.org/changeset/27040483

Ik vind het zelf ook lastig om te bepalen wanneer je die landuse=residential gebruikt. Als er ergens 3 huizen bij elkaar staan lijkt me dat overdreven, maar bij welk aantal dan wel? Ik heb daar al eerder in een dreaadje over gevraagd:
http://forum.openstreetmap.org/viewtopic.php?id=25189

Inmiddels heb ik de overbodige AND tags verwijderd waaraan mijn naam was gekoppeld, en dan met name in de directe omgeving van Vught.
Er bleven er toen nog wat over die door anderen waren getagd, maar omdat ook die nodes andere verkeerde tags hadden (unclassified ipv. residential) heb ik die maar meteen meegenomen en ook aangepast.

Als ik de procedure goed begrijp worden die tags die nog niet zijn verwijderd (evt. met mijn naam of die van een ander in de history), later gedaan als een mechanical edit, waarbij dan ook de history wordt aangepast.

Sorry had beginpost niet goed gelezen dacht dat het alleen om het verwijderen van tags ging ben dus een beetje laat.
Ik zie nu ook dat je source=3dShapes opnieuw toevoegt als een mapper deze actief heeft weggehaald en de ggmodelk heeft laten staan zie bv:

https://www.openstreetmap.org/way/55791853/history#map=14/52.3365/6.6365 (eerste de beste bosje in de changeset die mij wakker maakte)
Wat is de motivatie hierachter? Ik kan me zomaar voorstellen dat iemand deze tag weggehaald om aan te geven dat hij het betreffende polygoon zodanig heeft aangepast dat een verwijzing naar 3dShapes als bron niet meer op zijn plaats is. De ggmodelk code geeft alleen een landuse aan en is dan nog steeds geldig dus er was er geen reden om die weg te halen.
Weet iemand of er überhaupt bij de orginele import polygonen zijn toegevoegd zonder source tag?

Zie post #13 in deze thread

daar wordt alleen gemotiveerd waarom ggmodelk overbodig is, niet waarom het noodzakelijk is om source=3dShapes opnieuw toe te voegen. (behalve dan dat ligfietser zegt het een goed idee te vinden)

Concreet voorbeeld:
Ik gebruik de tag ggmodelk om al het ‘3dshapes’ grasland uit mijn kaart te filteren. Die 3dshapes graslanden zijn een enorm aantal sterk versnipperde polygonen en aangezien mijn kaart toch al lichtgroen is voegt dat nauwelijks wat toe en vertraagt het het renderen op de gps. Nu kwam men op het idee om al die tags maar te verwijderen en om toch de herkomst van die shapes te duiden heeft itsofunny source=3dshapes toegevoegd (de source tag had al lang bij de import moeten worden toegevoegd maar dat is achteraf praten).

Edit: excuses, 3d shapes had wel oorspronkelijk een source tag, ik was in de war met de AND import.

er zijn nog steeds 28.161 relaties met de “3dshapes:ggmodelk” tag. zie taginfo. is dit bewust gedaan?

Dat was een foutje. Inmiddels is dat voor Nederland hersteld.

Ik heb een vraagje over dit.

Het pand (grijs) staat boven een 3dShape (geel). Kan ik die 3dShape verwijderen en de tags overzetten naar de building? Op de kaart ziet het namelijk niet uit.
Ik geloof dat ik dit op andere plekken ook wel eens heb gezien.

De oorspronkelijke 3dShape-import is uit 2010 en klaarblijkelijk is bij de BAG-import uit 2016 iets misgegaan.
Ik zou inderdaad de tags overzetten en de oude verwijderen.

Dat is op zich geen reden om iets aan te passen (“taggen voor de renderer”). Ondergrondse parkeergarages die zichtbaar zijn op de kaart zien er nl. ook niet uit.

Voor mij is dat wel reden om iets aan te passen. Als landmeters of -uitzetters een rechte weg aanleggen en er lopen vervolgens wat mappers overheen waardoor die rechte weg als een soort verprutst breiwerk op de kaart komt te staan dan pas ik dat aan.
zie bijvoorbeeld hier:

waar negen nodes gebruikt worden terwijl vier voldoende zijn.
(ik ga daar overigens niks aanpassen, dat kunnen locals ook doen. Of ja, misschien ooit)

Met 3dshape zijn wel meer vreemde dingen gebeurt.
Op broeikassen ligt heel vaak een vlak met landuse=farm, ongeveer in de vorm van de kas.
Daar al de nodige van weg gehaald.

Inderdaad, bij de BAG import (punt G) diende gecontroleerd te worden op dit soort zaken.

Ik zou de 3dShape juist laten staan en de vorm ervan aanpassen aan het schoolterrein ipv het schoolgebouw. Net zoals je bij een amenity=school zou doen.
de polygoon rondom het terrein krijgt dan de volgende tags:


amenity=college
name=Gilde Opleidingen
website=https://www.gildeopleidingen.nl/over-gilde-opleidingen/locaties/groenveldsingel-venlo

source=3dShapes kan je wel weghalen, want van de oorspronkeleijke data is weinig meer over.

Het gebouw zou ik taggen met

building=college

Dat is ook een oplossing. Maar ik ging ervanuit dat die import het gebouw betrof en niet het terrein.