Ik kom tot zowat dezelfde conclusies, maar ik dacht dat zelf nominatim geen adressen toewijst aan nodes binnen een gebouw. Dus recentelijk map ik alle adressen dan maar dubbel. Het nut van associatedStreet relaties is dan ook maar weer beperkt tot die gevallen waar er geen gebied is aangemaakt met postcode grenzen en administratieve grenzen. Zelfs zonder associatedStreet relatie worden alle adressen mooi gevonden in Reet/Rumst waar die grenzen wel zijn.
m 2013/10/21 Jo <winfi...@gmail.com> > Ik ben al redelijk wat aan het experimenteren geweest met huisnummers. > > Met de tools die de JOSM plugin biedt, komen de nummers nogal gemakkelijk > op het gebouw terecht. > > Hier zie je een voorbeeld van het gebruik van nodes aan de voordeur: > > http://www.openstreetmap.org/#map=17/51.02572/4.73584 > > Wat ik daar handig aan vind, is dat zowel huisnummer als naam van > winkel/café gerenderd kunnen worden. > > Anderzijds vind ik het wat lastig om te beslissen wat we aan de > associatedStreetrelaties toevoegen. De adresnodes, de gebouwen of alles? > > Ondertussen heb ik me erbij neergelegd dat we op een 'hybride' manier > mappen. > > Voor de simpele gevallen, meestvoorkomend: op het gebouw > Als er meerdere adressen, brievenbussen of entiteiten (bedrijven, winkels, > kantoren, diensten) in het gebouw zijn: aparte nodes > > Ik ben er nog niet uit of ik het aanvaardbaar vind, om adresinformatie te > dupliceren. Twee zaken, in hetzelfde pand met hetzelfde adres. Eigenlijk > zouden we daar 2 nodes voor moeten maken en deze in de gebouwcontour > plaatsen. Het adres op de gebouwcontour. Het grote nadeel daarvan is dat je > een database met geografische mogelijkheden nodig hebt om dat te > interpreteren. Terwijl dat als je elke node van adresinformatie voorziet > (met de gemeenschappelijke tags in een AS-relatie), dan heb je genoeg aan > het XML-bestand met de gegevens. > > Jo > > > Op 21 oktober 2013 08:32 schreef Marc Gemis <marc.ge...@gmail.com>: > > Als je gewoon wil weten hoeveel brievenbussen er zijn, volstaat het om een >> (en ik bedenk hier maar wat) number-of-flats=4 of zo op het gebouw te >> plaatsen daarvoor heb je misschien die uitsplitsing misschien niet nodig. >> Maar ik kan me ook voorstellen dat het voor hulpdiensten handig is als >> men zegt dat ze op appartement 2 op huisnummer 199 moeten zijn en dat ze >> via (geavanceerde) navigatie tot aan de voordeur van het appartement >> (binnen in het gebouw) geleid worden. Verre toekoemst ? >> >> groeten >> >> m >> >> >> 2013/10/21 Guy Vanvuchelen <guy.vanvuche...@gmail.com> >> >>> We spreken over ‘huisnummers’ en ‘brievenbussen’. Hetzelfde en toch >>> verschillend. Huisnummers worden gebruikt voor navigatie. Maar >>> brievenbussen hebben dan weer belang voor postbedeling, meer nog voor >>> reclame, flyers, enz.**** >>> >>> Concreet kan het belangrijk zijn om te weten hoeveel brievenbussen er in >>> een bepaalde straat staan. Bijvoorbeeld verenigingen die flyers gaan rond >>> dragen, overlijdensberichten, reclamefolders. **** >>> >>> Nu vraag ik me af of we het gebouw het nummer moeten toekennen bijv. 4 >>> en op aparte nodes de brievenbus: 4/1, 4/2, enz.**** >>> >>> ** ** >>> >>> ** ** >>> >>> Guy Vanvuchelen**** >>> >>> ** ** >>> >>> *Van:* Marc Gemis [mailto:marc.ge...@gmail.com] >>> *Verzonden:* maandag 21 oktober 2013 7:27 >>> >>> *Aan:* OpenStreetMap Belgium >>> *Onderwerp:* Re: [OSM-talk-be] Newbie : Huis vatten**** >>> >>> ** ** >>> >>> Moeten we misschien ook geen onderscheid maken tussen outdoor en indoor >>> navigatie ? Een bus nummer is niet belangrijk voor navigatie buiten, wel >>> voor binnen het gebouw.**** >>> >>> Dan zouden we ook beter een andere tag gebruiken. Ik woonde vroeger op >>> een appartement, huisnr was 199 en had busnummer 2. Maar als er iemand op >>> bezoek kwam vermeldde we die "bus 2" nooit, enkel de straatnaam en nummer >>> 199.**** >>> >>> Op veel adresformulieren staat "bus" ook op een aparte plek. Voor mij >>> allebei redenen om te denken aan addr:busnumber of zoiets.**** >>> >>> ** ** >>> >>> Ik stel me bij dat hele huisnummer verhaal ook nog altijd een aantal >>> vragen. Het begint bij de keuzes die we maken: huisnnummers op gebouw en >>> het gebruik van associatedStreet, is dat wel de goede keuze voor de >>> toekomst ? Hoe passen POIs daarin ? Hoe kunnen we die huisnummers op >>> gebnouwen verfijnen als we busnummers en onderverdelingen in verdiepingen >>> willen mappen ? Hoe doet ze het in het buitenland (want het is voorlopig >>> nog steeds daar dat de software geschreven wordt) ? Gaan we ons niet teveel >>> isoleren ? **** >>> >>> ** ** >>> >>> Ik zal toch eens een aantal gevallen moeten bekijken in Brussel, >>> Denemarken, Duitsland, Frankrijk en Engeland. Proberen daarvan te leren. >>> **** >>> >>> ** ** >>> >>> Maar ja, ik zal wel een zagevent zijn :-)**** >>> >>> ** ** >>> >>> groeten**** >>> >>> ** ** >>> >>> m**** >>> >>> ** ** >>> >>> ** ** >>> >>> 2013/10/21 Marc Gemis <marc.ge...@gmail.com>**** >>> >>> ** ** >>> >>> 2013/10/20 Glenn Plas <gl...@byte-consult.be>**** >>> >>> Maar zoals steeds mappen we niet voor de renderer :) **** >>> >>> ** ** >>> >>> Onlangs nog gelezen dat we feitelijk deze zin te pas en te onpas >>> gebruikebnkt. We mappen feitelijk wel voor de renderer, we mogen alleen >>> niet iets misbruiken om de renderer te misleiden. (alleen was het beter >>> verwoord dan wat ik nu schrijf zoek maar eens op in het archief v.d. >>> tagging mailing list.).**** >>> >>> ** ** >>> >>> De punt-komma wordt altijd afgeraden in eender welke omstandigheid, >>> omdat de interpretatie ervan dubbelzinnig is. En het de verfijning van data >>> bemoeilijkt. Gesteld dat iemand later verdiepingen wil toevoegen aan de >>> individuele bus nummers, moet die dan ook punt-komma's gebruiken ?**** >>> >>> ** ** >>> >>> Dus individuele punten is de beste manier.**** >>> >>> ** ** >>> >>> groet**** >>> >>> ** ** >>> >>> m**** >>> >>> ** ** >>> >>> _______________________________________________ >>> Talk-be mailing list >>> Talk-be@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-be >>> >>> >> >> _______________________________________________ >> Talk-be mailing list >> Talk-be@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-be >> >> > > _______________________________________________ > Talk-be mailing list > Talk-be@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-be > >
_______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
