Voor beide methode is wat te zeggen alleen voel ik bij mij (en hoop ook bij anderen) sterk de behoefte aan standaardisatie én differentiatie.
Mijn vraag:
Is het een goed idee om vaste OSM NL afspraken te maken tussen:
magazijn (van een winkel)
en
Distributie Centra.
De eerste taggen we dan als building=warehouse (of in geval van winkel-magazijn room=warehouse) volgens room=*
De tweede taggen we dan als building=industrial + industrial=warehouse.
De behoefte bij mij om onderscheid te maken:
Magazijn zie ik als relatieve kleinschalige en/of passieve opslag van goederen.
Distributie Centra als grootschalige opslag én inpandige herverdelings-processen zodat bulk ingekochte goederen ver- & herpakt worden voor verdere distributie.
Graag wat meningen en/of opmerkingen van iedereen.
Voor vrachtchauffeurs is het onderscheid willen maken in OSM echter wel van belangóók kwa routering.
We taggen toch nooit louter alleen voor ons zelf ?
Én je creëert eenduidigheid in tagging waarbij je niet als OSM-‘predikant’ de ene manier of de andere manier van tagging wil uitsluiten…
Dus nee, deze tags zijn niet geschikt om een onderscheid te maken tussen groot en klein.
Ik denk dat bijna alle kleine magazijnen te mappen zijn als room=warehouse en als het een apart gebouw is dan zegt de grote van het gebouw in OSM hoe groot het gebouw daadwerkelijk is.
building=warehouse is volledig synoniem met building=industrial + industrial=warehouse. Het is dan niet handig om daar in één land een kunstmatig onderscheid in te gaan leggen; dat zou OSM-breed (maar ook al in NL, want veel mappers zitten niet op dit forum) dan toch niet zo begrepen worden.
nu zonder onderscheid door elkaar gebruikt blijven worden.
Dit terwijl juist het onderscheid tussen:
magazijn, mega magazijn ter grootte van DC’s (recente ontwikkeling door het webwinkel fenomeen zonder tussenkomst van groothandel de klant te willen bedienen)
&
distributiecentrum (old school)
Het voor vracht-vervoerders makkelijker zou maken maakt kwa routing.
Immers bij type: magazijn is het niet van belang aan welke docking kant je je order ophaalt.
Bij DC (old school) wel.
Bij een winkel magazijn in bebouwde kom is het juist weer makkelijk omdat je dan meteen naar de juiste kant van de winkel gerouteerd kan worden…
Door geen differentiatie toe te passen in OSM mis je een logische en symantische kans om juiste routing toe te kunnen passen…
Da’s slechts een kwestie van wiki pagina’s aanpassen.
Aan de andere kant: waarom als er dan tóch 2 manieren in OSM zijn (magazijn aan de ene kant & distributiecentrum old-school aan de andere kant) objecten te taggen en dit tot verwarring kan leiden dit dan niet logisch & semantisch in OSM te repareren ?
Dus mijn verweer is, je doet het om in OSM 1-duidigheid te creëren & meteen een definitie kronkel te repareren op OSM globale schaal want het kan universeel en dus niet alleen in Nederland toegepast worden.
Nou overleggen hier hè & barrière’s die opgeworpen worden afbreken met argumentatie.
Met als einddoel: meer structuur te krijgen in warehouse tagging door én definitie reparatie én 1-duidige tagging.
Als ik de Tag:industrial=warehouse wiki lees staat er toch echt:
Add:
landuse=industrial
industrial=warehouse
name=*
Helaas laat taginfo geen Combinations zien omdat de tag te weinig gebruikt wordt maar ik je vertellen, door te zoeken in een planet file dat:
7580 van de 9448 objecten (80%) met industrial=warehouse ook landuse=industrial hebben zoals bedoeld
911 van de 9448 objecten (10%) building=industrial met industrial=warehouse hebben
Lijkt me sterk dat als je de Wiki pagina aan past om dat het laatste te herdefiniëren dat als zodanig blijft bestaan en belangrijker ook door gebruikers zo gebruikt gaat worden.
Als ik je goed begrijp wil je voor “DC (old school)” het dock aangeven waar een chauffeur iets moet ophalen, heb je al een voorstel voor dat? Ja, net als voor een zwembad zou ik graag hier een voorstel voor zien, misschien is wat je nu voorstelt daardoor helemaal niet nodig.
En is ook helemaal correct voor de grond rondom het gebouw (willekeurig mag dat een magazijn of distributiecentrum zijn in OSM) daar mag je nu willekeur in tagging in aanbrengen…
Als je echter in de wiki zoekt naar warehouse dan… (precies waarom ik warehouse-tagging als onderwerpstitel gekozen heb)
Welke volstrekt helder uitlegt hoe 1 & ander te taggen…
Als er ruis is ontstaan in wiki-documentatie dan kan ik alleen maar zeggen: wiki-documentatie creëren blijft mensen werk en het is niet het enige onderwerp in OSM-wiki waar zo nu & dan foutjes in sluipen toch ?
Nee die verfijning komt in een later stadium maar goed dat je het aangestipt hebt !
Wél kun je alvast bijvoorbeeld de aanwezig van toeleveranciers-docking-zijde & filiaal-docking-zijde van een DC (old school) aan een routingprogramma mee geven.
Als je middels mijn voorstel:
building=warehouse (voor magazijn of mega-magazijn)
/
room=warehouse (uitbreiding op room=* waarde voor winkel-magazijnruimte)
&
building=industrial + industrial=warehouse voor distributie centra
op deze manier onderscheid maakt, dan bereid je een routing-programma (door aanwezigheid van building=industrial + industrial=warehouse definitie) voor op het feit dat je een supplier- docking kant hebt & een branch-docking kant hebt van het gebouw…
Wat routing naar de juiste docking kant makkelijker maakt…
Een voorbeeld:
een Jumbo-supermarkt DC koopt groot in bij toeleveranciers en deze goederen worden afgeleverd aan de toe leveranciers docking-kant.
Binnen in het gebouw worden de verschillende aangeleverde goederen verdeeld in afzonderlijke Jumbo supermarkt filiaal-transporten en aangeboden aan filiaal docking gebouw zijde voor transport naar de juiste Jumbo-supermarkt filialen.
De afzonderlijke filiaalvrachten worden of: opgeslagen in regio magazijn gebouwen (building=warehouse) voor verder afzonderlijke filiaal transporten voorbereiding of rechtstreeks naar bewuste plaatselijke supermarkt vervoerd.
Kwa routing naar een supermarkt magazijn is het dan handig dat de chauffeur niet voor de deur van de supermarkt aan de voorkant geleid wordt maar meteen naar het juiste supermarkt magazijn (room=warehouse) van bewuste supermarkt meestal aan de achterkant…
Helemaal in steden zoals Haarlem, Groningen, Amsterdam enzovoorts die dol zijn op éénrichtingswegen & -straten…
Ik gebruik zelf building=warehouse voor distrivutiecentra. Dan hoef je niet zonder reden twee tags te gebruiken.
Een onderscheid tussen groot en klein zou ik met een secundaire tag maken, als je het al wil maken. Dat verschil lees je niet af uit het veschil tussen building=industrial+industrial=warehouse en building=warehouse.
Je bereid geen routing programma voor, er veranderd niks aan bestaande routing programma’s.
Hoogstens maakt je het eventueel mogelijk dat een nog niet bestaand routing programma hier in de toekomst gebruik van zou kunnen gaan maken, mits dit tagging schema voldoet aan hun nog onbekende eisen.
Ik vind amenity=loading_dock zoals gevonden door @Kin_Sapalot een veel beter idee.
Als de verschillende laadplatformen een identificatie hebben kan je dat taggen met ref=A of ref=Haarlem en dan kan je zeggen ga naar laadplatform A en done. Je kan zelfs service wegen aanleggen naar dat laadplatform.
Da’s beetje kip ei verhaal…
Als er geen structurering op dit onderwerp in de OSM database plaats vindt kan een routingprogramma er niets mee en zal er niets veranderen…
Een beetje slim in gericht routing programma hoeft (even als scope afdichting alleen kijkend naar warehouse onderwerp) bij de bestemmingskant alleen te scannen op: building=*.
Zoals ik de inrichting grof voor ogen heb: Is de waarde van building warehouse dan hoeft er niet naar een dockingszijde gekeken te worden maar alleen naar het dockingsnummer.
Is er geen building maar wél warehouse als waarde in het object dan routeer je naar de room=warehouse lokatie…
Dan ga je voorbij aan het feit dat er óók gerouteerd zou moeten kunnen worden naar: room=warehouse lokatie’s waarbij er geen amenity=loading_dock in het object is opgenomen omdat er fysiek geen loading dock aanwezig is maar slechts een te openen rolluik bijvoorbeeld…