Bij het bekijken van het Outlet Center in Roermond op OSM vielen mij een aantal dingen op waar ik graag wat advies over wil.
Er missen nog veel winkels en sommige al toegevoegde winkels kloppen niet meer. Is het toegestaan om met behulp van de kaart van het outlet zelf [1] de winkels te updaten? Naast dat ik niet in de buurt ben is veldwerk in het outlet niet mogelijk met de huidige maatregelen.
De winkels staan niet op de adresnode maar op een vlak met building:part=retail. Is dit een uitzondering op de regel om winkels op de adresnode te taggen? Daarnaast lijken sommige huisnummers in de vlakken met building:part niet overeen te komen met de huisnummers van de adresnode. Ik kan de bron die gebruikt is voor het intekenen van de building:part vlakken niet terug vinden om het te controleren (Al moet ik met de plattegrond van het outlet een eind komen).
De parkeerplaats is recent aangepast. Wijzigingen zijn nog niet zichtbaar op de PDOK luchtfoto’s of BGT. Ze staan wel al op de NSO latest maar die is te grof om op te kunnen intekenen. Kwestie van wachten tot de BGT en luchtfoto’s zijn geupdate of heeft iemand nog een tip hiervoor die ik niet ken?
Ik zie geen probleem om algemeen publiek toegankelijke data daarvoor te gebruiken. Corona verhindert verificatie in het veld; er is wellicht een klein risico dat ook de folderinformatie niet meer up-to-date is.
Ik heb zelf onlangs een BAG-update gedaan (op verzoek); de building parts komen niet uit de BAG en zijn door een ander handmatig ingevoerd. Ik heb die building parts natuurlijk wel op een paar plekken aan de nieuwe BAG-outline moeten aanpassen. Ik weet niet de bron van de building parts, noch of de outlines juist zijn. Ik zelf ben niet zo’n voorstander van building parts (voor 3D-representatie worden building parts met verschillende hoogte wel toegepast, maar dat lijkt mij hier niet aan de orde). Normaliter wordt inderdaad de winkel en andere gegevens aan de adresnode gekoppeld; ik weet niet, vermoed wel, niet gecontroleerd, dat de winkels een eigen adresnode hebben; geen bezwaar van mijn zijde om de winkels aan die nodes te koppelen.
Ook aan de parking heb ik op verzoek wat aangepast; inderdaad niet op BAG/BGT. Je kunt het naar eigen inzicht aanpassen. Let wel: vaak heeft een ondergrondse parking een andere (grotere) outline dan het pand op maaiveld; het gewoon intekenen van die parking levert dan op de standaardkaart een beeld op dat je op maaiveld niet herkent. Ik weet niet of de standaardweergave inmiddels kan omgaan met tags als location=underground en layer=-1 voor gebouwen inzake rendering. Wellicht een geval van taggen voor de renderer, maar ik tag niet ondergrondse gebouwen die je op maaiveld niet ziet. Maar dat kan persoonlijk zijn.
De winkels lijken een eigen adres te hebben [1]. Ze staan echter niet op de website van het outlet zelf dus dan zal ik alle winkels apart moeten opzoeken om aan die info te komen. Ik zal even wachten met omzetten van de winkel van de building:part naar adresnode. Misschien heeft iemand anders een andere mening.
Ik zal even kijken. Het zijn wel bovengrondse parkeerplaatsen. Volgensmij zijn het een soort premium parkeerplekken van wat ik mij herinner toen ik er de laatste keer was. Is het anders mogelijk om het zoomlevel van een afbeelding vast te zetten in JOSM? de NSO latest verdwijnt als ik verder dan dit in zoom. Ik zal ook eens kijken of ik ergens ontwerptekeningen kan vinden. Misschien bij ruimtelijke plannen.
Over punt 1: Het gaat erom of de openbare data een hoofd- of bijdoel van de organisatie is. Het hoofddoel van de designer outlet is winkels verhuren aan kledingverkopers en die faciliteren. Het publiceren van een kaartje is geen hoofddoel, dus dat m
De makkelijkste vergelijking is als je een telefoonnummer en openingstijd van een supermarkt op OSM wil zetten. Die data mag je wel van AH.nl halen (hoofddoel: eten verkopen), maar niet van Google Maps, Telefoongids.nl of openingstijden.nl (hoefddoelen: Bedrijfsinformatie verzamelen)
Waarschijnlijk komt mijn naam in de historie van de building:part invoer naar voren.
De gebouwen heb ik ooit uit de BAG gehaald (lange tijd geleden). De (vele,kleine) bestaande gebouwen heb ik toen omgezet naar building:part om de invoer van andere mappers niet verloren te laten gaan. Ik verder niet veel gedaan of de namen van de winkels nog klopten.
Zo goed mogelijk heb ik toen de building:part outlines aan de buitenkant van de gebouwen aan de building outline aangepast.
Het is al weer meer dan een jaar geleden dat ik er was, maar de parkeerplaatsen waren toen bovengronds. Als je de afslag naar de parkeerplaats nam, dan kwam in de in de parkeergarage terecht. Reed je door dan kon je op het parkeerterrein parkeren.
Zo had ik er nog nooit naar gekeken maar mooi, dan kan ik hem als referentie gebruiken.
Ik zag je idd in de geschiedenis staan. Is het dan een idee dat ik de building:part laat staan en de winkelinformatie op de adresnode zet zoals de afspraak is in NL? Dan behoud ik die informatie.
Ik heb de NSo latest nu zodanig in JOSM dat ik verder kan inzoomen. Dan zal ik op basis daarvan de parkeerplaats aanpassen. Is hard nodig:
Ik vind het prima.
Of de building:part veel toevoegt weet ik niet, maar in principe probeer ik geen informatie van andere te verwijderen.
De ondergrond verdwijnt als er geen data meer is voor dit zoom bereik.
Je kunt dit oplossen door een getal achter de wms link te zetten bij de voorkeur instellingen.
Bv. wms[18]: ipv wms:
Ik zie er ook de toegevoegde waarde niet echt van in maar goed, iemand heeft veel werk daarin gestopt.
Bedankt voor de tip, ik zal er eens naar kijken. Ik had nu in Qgis een tif afbeelding van eem stukje NSO latest gemaakt en die in JOSM ingeladen maar jou methode is natuurlijk gemakkelijker.
Ik zie nu in JOSM dat hij een waarschuwing op alle gebouwen geeft van overlappende gebouwen. je hebt nu dus het gebouw vanuit de bag en een los object met building:part=retail (wat als source bag heeft) wat door JSOM ook als gebouw wordt gezien.
Is het misschien een idee om al die vlakken dan als indoor=area te taggen? Het klopt dan niet helemaal maar dan behoud je wel die indeling en je werkt die error zo (hopelijk) weg.
Ik zie ook dat er nu dubbele adressen staan ( 1x op het vlak met building:part=retail en 1x op de adresnode). Ook een zoekopdracht in OSM geeft 2x de zelfde adressen ( dan 1 met winkel en 1 zonder).
Enig idee hoe dit opgelost kan worden want zeker die dubbele adressen lijken mij niet wenselijk. Mogelijke oplossingen:
Ik tekenen een lijn tussen de winkels (volgens de huidige vlakindeling en indeling plattegrond outlet) en geef dat de tag indoor=wall. Gevolg is wel dat het dan wss renderd op carto en het niet 100% correct is met de werkelijke winkelindeling.
Ik alle tags van die vlakken haal, en er een note tag op zet zodat de winkel indeling wel intact blijft voor toekomstige mapping maar dat het niet echt als OSM data geld.
Ik de originele mapper een bericht stuur, de situatie uitleg en vraag of hij er, ondanks al zijn werk, mee akkoord is dat het verwijderd word.
Dubbele identieke adressen horen natuurlijk niet. Het Nederlandse gebruik is het adres als een (BAG)-node te plaatsen en niet op een building of building part. Det geldt dan ook voor de naam ven de winkel.
Ik zie er geen bezwaar tegen dat al aan te passen en in je changeset de reden te noemen.
En wat zal ik dan aanpassen? Het vlak met het adres helemaal verwijderen of indoor tagging gebruiken om toch de winkelindeling te behouden (dan wordt het ook op carto gerenderd)
Stapje voor stapje, waar voor ieder stapje overleg nodig kan zijn.
Het verplaatsen van de adres en winkelinfo naar een (BAG) node kan wat mij betreft zonder overleg.
Ik had al gezegd zelf geen voorstander te zijn van building parts (ik zie alleen een toepassing voor 3D rendering van gebouwen, OSM is m.i. niet voor binnenhuisarchitecten). Die building parts zou ik zeker niet zonder overleg verwijderen. Controle op juistheid is een andere zaak. Als je de adresnodes op de juiste plek zet komen de winkels daarmee ook op de juiste plekken.
Ja, hier ben ik al mee begonnen. 40-50% van winkels klopt sowieso al niet meer als ik het met de website vergelijk.
Ik zal de eerste mapper even een bericht sturen. Ik snap overigens je standpunt over indoor mapping. Dan zal ik proberen toe te werken naar een oplossing waar dat niet gebruikt hoeft te worden. Inderdaad, als de adrespunten (en dus winkels) maar goed staan lijkt het mij ook prima zonder indeling.
