Kent een van jullie “sebastic”? Ik ben die naam al vaker tegengekomen als editor, en had het idee dat hij / zij serieus bezig was, maar zie nu ineens 9 “gemeentehuizen” (amenity=townhall) op het Bedrijventerrein De Kool bij Woensdrecht…
Uit de history blijkt dit door sebastic te zijn aangebracht op de oorspronkelijke BAG nodes… (EDIT: klopt niet! Mijn fout, verkeerde interpretatie van helaas onvolledige historieweergave op de site, lees mijn volgende post hieronder voor details.)
Ook de tag “designation”, lijkt ver van de oorspronkelijke betekenis in de Wiki:
Als je in de history van de objecten kijkt zie je dat ik alleen de addr:city tags van de objecten heb gecorrigeerd, er waren daar zowel BAG als niet-BAG adres nodes en deze zijn destijds gemerged.
Ah, sorry, mijn oprechte excuses, ik kon mij eerlijk gezegd al totaal niet voorstellen dat dit van jou kwam, ik werd echter door de History view van de OpenStreetMap site ernstig in de war gebracht, want ik begin mij te realiseren dat daar wel forse beperkingen in zitten. Ik had namelijk juist al geprobeerd via de OpenStreetMap site te achterhalen wie daar nu voor verantwoordelijk was.
Via de History link op de OpenStreetMap site zie ik alleen wat je hier ziet:
en vervolgens bij jouw versie 2 de extra tags zoals amenity=townhall en designation=x. Begrijp ik nu uit jouw opmerking dat de extra tags ontstaan zijn door het “mergen” van nodes, en deze tags dus op een tweede node stonden die nu dus door jouw merge verwijderd is?
Het is wel een beetje waardeloos dat de history view daar niet voor waarschuwt… Met deze weergave lijkt het alsof de tags door de laatste editor zijn toegevoegd, wat dan dus totaal niet klopt. Dan moet je dus echt de changeset XML door gaan spitten om echt te achterhalen wat er gebeurd is… als het daar al terug te vinden is?
Ik heb nu ook in JOSM naar de history proberen te kijken, en ook de osmChange-XML. Ik begin mij nu echter te realiseren dat het volgens mij niet direct mogelijk is om de historie van een dergelijke “node-merge” te achterhalen, gezien de structuur en data die in een changeset wordt opgenomen. De edit-handeling “merge” staat er natuurlijk niet in, alleen de gewijzigde, toegevoegde en gedelete objecten. Je moet dan echt elke gedelete node af gaan lopen om te kijken welke de oorspronkelijke tags had?
Kan iemand mijn laatste vermoedens bevestigen, dat je een dergelijke “merge” eigenlijk niet goed of totaal niet in de verschillende history views kan achterhalen? Dat is toch wel iets om stevig rekening mee te houden als je de history van een object wilt bekijken…
Ik zal vandaag proberen dit te corrigeren. De designation haal ik dan ook weg. Bedrijfsinformatie opnemen bij nodes lijkt mij totaal zinloos. Het enige echt nuttige is evt. een website…
Omdat de oude nodes verwijderd zijn, is het lastig diens historie terug te halen vanuit de huidige situatie. Mijn advies voor dit soort situaties is de changeset in JOSM te reverten (in een aparte laag), dan kan je de oude situatie beter beoordelen en heb je eenvoudig toegang tot de historie van de oude nodes.
Nu de onjuiste tagging is verwijdert, renderen de bedrijven niet meer op de standaard OSM kaart.
Wat ik persoonlijk meestal doe is de adresnode samenvoegen op de pandcontour.
Natuurlijk weet ik dat we niet voor de renderer mogen mappen, maar het samenvoegen op de pandcontour vind ik hier geen voorbeeld van.
Is er een andere mogelijkheid om op een meer legitieme manier te taggen zodat je het ook op de standaard mapnik (OSM) kaart kunt zien?
Bij het gebruik van de reverter plugin kun je de changeset van sebastic inlezen.
(De feitelijke revert vind alleen plaats als je de revert upload, zolang je dit niet doet kun je alles inzien)
In onderstaand plaatje is te zien dat de node leeg gemerged is naar een bestaande andere bestaande node.
De nieuwe tags in de BAG node te staan, terwijl de oude node leeg is en verwijdert wordt na merge.
Uiteindelijk ben ik het met je eens dat snel geoordeeld wordt dat iemand iets heeft gedaan, het blijkt dat dit lang niet altijd het geval is. Het is geen “bug” in de history van de node, de node is namelijk verwijdert, en de historie van de oude node blijft aanwezig in OSM. Wel is dit, zoals sebastic ook al aangeeft, lastiger om terug te halen.
tip: open het plaatje met rechtermuisknop voor een leesbaar exemplaar
Bedankt voor de reverter tip! Ik moet mij inderdaad eens meer in dat deel van JOSM verdiepen, het is een deel waar ik nog onvoldoende naar gekeken heb.
Ik ben het met je eens dat het zeker niet om een “bug” gaat, maar om een technische beperking waar ik zelf nog niet voldoende bij stil had gestaan. Omdat ik dit nu weet, zal ik daar een volgende keer zeker beter rekening mee houden!
Als het om bedrijven gaat die ook voor (professionele) klanten een winkel / groothandel voeren, zoals op best wel wat bedrijventerreinen frequent gebeurd, dan is shop=x natuurlijk de oplossing. Ik heb bij mijn wijzigingen niet meer gekeken of er nog een relevante shop tag voor elke individueel bedrijf was (ook niet zo makkelijk uit te zoeken “op afstand”).
Gelijke behandeling, en al die andere bedrijven die geen shop en office zijn.
Elk bedrijf heeft wel een hoekje met een bureau, dat maakt het nog geen office.
Dat is eigenlijk wel de kern van dit topic probleem, de render bepaald, osm carto is een bepalende kaart, wat op de kaart komt.
Vandaar waarom niet alle bedrijven op de adrestag (node) de name laten zien.
Ik kan me ook een tag value, B2B, voorstellen, business to business.
(professionele klanten) wat is dat, bedrijven die alleen een klanten verkopen met een Kvk nummer, of tot een bepaalde branche horen of aan een ieder die professioneel spul wil.
Kan me ook, B2C B2CB voorstellen.
Een shop, dat voelt meer als, iedereen kan binnen stappen en producten van het schap pakken.
Er zijn genoeg groothandels met een afhaalbalie, met een display ervoor met producten (waar geen prijzen bij staan). Afspraken kortingen op de brutoprijzen. Daar heb je als individu niks te zoeken, denken sommige andere weer wel.
Ik heb hier wel eens gelezen de opmerking, we zijn geen gouden gids. Dat zijn we ondertussen wel. Vandaar gelijke behandeling.
Geef je de een de mogelijkheid om op een kaart te komen staan, geef dat de ander ook. (mogelijkheid tot voorkomen in de database). Open source, dat is het toch de bedoeling.
als het bedrijf geen office of shop is kan je bv. ook man_made=works (fabriek) op de node zetten. Voor een garage van een transportbedrijf weet ik ook niet zo goed welke tag je zou kunnen gebruiken.
Een naam op een gebouw wordt ook gezien als de naam van het gebouw, dat is niet noodzakelijk de naam van het bedrijf in het gebouw. Persoonlijk vind ik het geen goed idee om de naam van een adrespunt op de kaart te tonen, zonder dat er een extra classificatie (shop, office, man_made, …) bijstaat.
Het was ook niet de insteek om jou te laten zoeken naar juiste tagging.
Mij ging het erom om toch een industrieterrein inzichtelijker te maken. Maar helaas wordt office=* niet gerenderd.
Dan blijft (voor mij) maar 1 ding over, de naam op het pandcontour met een man_made=, office= of shop=*
Persoonlijk heb ik geen ervaringen met github en requests etc… Maar ongetwijfeld zijn deze verzoeken al aan de orde geweest, en zie me niet als persoon om deze kar te trekken.