// @name GLS
[out:json];
{{geocodeArea:Netherlands}}->.searchArea;
(
way["amenity"="post_depot"]["operator"="General Logistics Systems Netherlands B.V."](area.searchArea);
);
out geom;
Op het eerste gezicht vind ik ze wel heel netjes consequent gemapt zo met het hek, wegen, parkeerplaats etc. Maar vraag me namelijk af of voor een bedrijf de naam wel op het perceel thuishoort. Zou ook naar de BAG-node kunnen. Ook dat interne referentienummer van het depot zoals NL6500 hoort denk ik niet in de naam thuis (dit nummer zal niet zichtbaar zijn op het pand, GLS als naam is genoeg m.i.), het staat ook al keurig in ref.
Dus mijn voorstel zou sowieso zijn de bedrijfspecifieke tags te verwijderen van de perceelomtrek en op de BAG-node: name=GLS operator=General Logistics Systems Netherlands B.V. ref=NLxx amenity=post_depot
Zo verdwijnt de informatie niet en staat dan samen met het adres op 1 node.
Wat vinden jullie hiervan? Kan de bewuste mapper ook een bericht sturen. Die GLS-depots zijn door 1 mapper (vermoedelijk een Duitser) toegevoegd zo te zien.
Gerelateerd vraag / discussiepuntje:
Of landuse=commercial moet blijven bestaan vraag ik me ook af, vind het wel apart om 1 specifiek bedrijf op een bedrijventerrein commercial te geven terwijl dit terrein zelf al landuse=industrial heeft. Maar ik zie dat dit wel vaker is toegepast in NL en het is niet overduidelijk fout. Ergens in Groningen kwam ik een lappendeken tegen van commercial, retail en industrial.
Mogelijk past commercial zelfs beter voor een logistiek magazijn (er wordt tenslotte niets gefabriceerd). Echter voor heel veel bedrijventerreinen in Nederland met landuse=industrial zal gelden dat er voornamelijk magazijnen en kantoren te vinden zijn.
Bij grote bedrijfspercelen vind ik het eigenlijk helemaal niet raar om het hele vlak te nemen voor de data. Bij het formaat van een grote fabriek (man_made=works) is dat zelfs wenselijk.
Neem deze bijvoorbeeld. Dat is een groot terrein (met een lokale geschiedenis) in een complexere vorm. Met alleen een node druk je daar niet de grootte van het complex mee uit, en verlies je informatie. Dat is bij een winkel met één pand en een beperkt (of gedeeld) perceel niet zo’n probleem, maar bij zo’n megaterrein is dat wel anders.
Die grote blokkendozen van de pakjesdiensten zijn een tussenmaat, maar vaak ook al behoorlijk groot. Ik zie dat daar niet als fout om de amenity op het vlak te zetten. Eigenlijk zelfs wenselijk. Daarnaast doen we dit bij andere grote voorzieningen ook (ziekenhuizen, scholen, rioolwaterzuiveringsinstallaties, etc.).
Welk probleem lossen we bij zulke grote percelen op door de ruimtelijke informatie op te geven en het terug te brengen tot de adresnode? Als die mapper het netjes doet, lijkt me de keuze goed te verdedigen.
Oh dat klopt! Maar dat is historisch zo gegroeid met bulkimports en grove lijnen. Het klopt inderdaad vaak niet, en het komt volgens mij deels omdat we in het Nederlands ‘bedrijventerrein’ en ‘industrieterrein’ soms door elkaar gebruiken.
landuse=commercial lijkt me dan ook zeker correct voor een pakketjesdepot. Er wordt immers een dienst geleverd zonder productie.
Dat kan zeker. Wat hier ook speelt is dat veel klassieke industrieterreinen dichter bij de stadskern langzaam veranderen van rol. Dat schuift vaak naar dienstverlening en (grotere) retail op, en soms deels naar een woonbestemming.
Er is niets mis met zulke gemixte gebieden op de kaart. Dat is nou eenmaal wat daar is.
Het terrein zelf is sowieso netjes in kaart gebracht dus daar wil ik niets aan veranderen.
Vind het nu wel jammer dat de bedrijfsinformatie niet aan het adres is gekoppeld. Dat maakt het lastiger voor data consumers om goede adres te tonen. Als je in Nominatim zoekt op “GLS Wijchen” krijg je als straat Wilhelminalaan te zien maar daar ligt de ingang van het pand helemaal niet aan.
Maar goed voor nu ga ik hier helemaal niets aanpassen als er geen overduidelijk fout is en beschouw de melding van Osmose hier dan als een false positive.
Dat mag je ook oplossen door het adres er gewoon bij te zetten. Je hebt dan ter plaatse twee keer datzelfde adres:
Als (kale) adresnode
Als kenmerk van de voorziening
Omdat we adresnodes kaal importeren uit de BAG, hebben we deze dubbeling dan, maar dat is eigenlijk niet zo erg; het zijn twee verschillende functies. Bij een ziekenhuis of educatieve instelling kan dat immers ook (als ze een duidelijk hoofdadres voeren). Overigens komt een dubbel adres ook voor wanneer winkels eenzelfde adres delen, of er twee andere verschillende POI’s op hetzelfde adres zitten. Wanneer het adres als attribuut toegepast wordt kan dat gewoon.
Wat is de melding van Osmose trouwens? Ik zie bij dat GLS Depot wel dat barrier=fence als attribuut gebruikt wordt. Dat wordt ook wel afgeraden. Het nadeel is dat je bij het los intekenen van barrier=fence soms exact dezelfde way krijgt als het vlak, en daar zeurt een QA-tool dan ook wel over. Dat is niet terecht, maar zet mappers wel eens op een vals spoor.
Oh ja, ik zie het. Ik denk niet dat een terechte melding is in dit geval. Je zou denken dat amenity=post_depot wel landuse=commercial impliceert (dat is niet zo gedocumenteerd), maar het lijkt me niet fout om het expliciet te maken.
Ik zal amenity=post_depot in Leeuwarden ook eens toepassen trouwens. amenity=post_depot is de laatste jaren behoorlijk gegroeid in populariteit.
Zijn er nog tips om goed met die situatie te kunnen werken in JOSM? Bij een ander filiaal is het hek wel los van landuse ingetekend, waarbij ook de poorten als ways zijn ingetekend. De landuse volgt de combinatie van hekstukken en poorten (zelfde ways).
Alleen stuk barrier=fence geselecteerd met ways die ook in landuse zitten:
Is er een sneltoets o.i.d. om de landuse makkelijk te selecteren? Of kan het niet anders dan alle losse delen selecteren en het selectievenster gebruiken? Een filter die alleen landuse actief maakt kan natuurlijk ook maar vaak blijken er handige functies in JOSM te zitten die ik niet ken vandaar de vraag
Zou daar iets handigs voor zijn? Ik doe het altijd via een trucje dat een beetje als een omweg voelt: ik selecteer een vlak, en als het niet de juiste is sleep ik één lijn even een stukje naar buiten om een nieuwe (tijdelijke) node te creëren. (Die node gooi ik weer weg als ik klaar ben met die vlakken.)
Heel af en toe, als een hek of andere barrier precies de omtrek van een deel van de landuse volgt, gebruik ik een multipolygon met de barrier als een van de outers. Dus zonder inner.
Ook toepasbaar bij bv een centraal eiland van een rotonde, omringd door een kerb.
Ik weet niet of ik je goed begrijp maar met ALT+linkermuisknop meerdere keren klikken kun je switchen tussen de elementen waar het lijnstuk onderdeel van uitmaakt zodat je het juiste element selecteert.
Maar heb je toevallig ook een truc om, als alle landuse-vlakken aan elkaar zitten, en je hebt er een of meer al geselecteerd, dan nog eentje erbij te selecteren, als die ene zich niet wil laten aanklikken omdat control-klik telkens een andere kiest dan jij wil?
Ik weet weer niet of ik het goed begrijp maar met ALT+SHIFT en linkermuis klikken verandert ook de selectie. Wellicht staat hier nog iets dat kan helpen.
Even voor de duidelijk je bedoelt dat (in het geval van voorbeeld GLS) de landuse en bedrijfspecifieke tags op de relatie van type multipolygon komen en de wegen met barrier=fence als leden van die relatie met rol outer?
Niet iedere mapper is hier fan van, maar het is een bestaande mogelijkheid in OSM.
In sommige landen is het veel gebruikelijker om bv wegen of waterwegen als outer te gebruiken voor een bos of zo. Of zelfs delen van een gebouwomtrek. Dat is heel erg onhandig als je daar ooit iets wil aanpassen, daarom wordt in NL afgeraden en daar ben ik het van harte mee eens.
Maar in dit soort gevallen waar een lineair element echt de omtrek vormt van de area, en verder niet aan nog meer dingen vastzit, vind ik het een betere oplossing dan de alternatieven.
Ja, dat helpt wel! Middelklik, ik had er niet aan gedacht, maar dan krijgt je een popup waarin je een selectie kan maken, ook een mulitple selectie. Je kan dan (niet gewoon willekeurig bijselecteren met control, maar wel meerdere aangrenzende area’s. Bijvoorbeeld om ze met shift-J samen te voegen.
