[OSM-talk-nl] Geotagging workshop in Brussel
Beste mensen, In de week van 15 september wordt een workshop gehouden over geotagging en locative media. Ze zoeken nog een x-aantal mensen die wat workshops in het veld willen geven. Heeft een van jullie tijd en zin? Waar gaat het ongeveer om. Doelgroep zijn ontwerpers, kunstenaars, etc. Dus niet zozeer techneuten. Het event duurt een week. De eerste twee dagen zijn indoor, en zal door iemand worden verzorgt die wat meer ingaat op de kunst van het wandelen (wat zie je eigenlijk) en geo-based technieken. De twee/drie dagen daarop volgend gaan de mensen de straat op met een GPS om data te verzamelen en deze worden later die dag verwerkt. Het verwerken zal op verschillende wijzen worden gedaan. Van simpele zaken als foto's en video's op Google Maps/Earth zetten tot mogelijk een eigen kaart maken. Maar alles vanuit een artistiek perspectief. Kortom, wie heeft zin om een of meerdere dagen enkele creabea's te helpen met het maken van leuke dingen? Ik weet, deze info is wat beknopt. Bel of mail (af en toe ben ik ook op Skype te vinden) even, dan kan ik je wat nadere info geven. Gr, Henk Hoff ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] Kenmerk: e2008-01832 (fwd)
Om jullie ook even op de hoogte te houden. In het kort; ik zou graag een thema (straat) kaart maken, waar gevallen van een ziekte (in absolute aantal) worden gevisualiseerd op straatniveau en in vlakken op wijkniveau (genormaliseerd en niet genormaliseerd). Uit de onderstaande email maak ik op dat er alleen als je alle huisnummers afbelt op een postcode en aan iedereen zou vragen of hij [die bepaalde ziekte heeft] inzicht kan krijgen in de data. Echter deze bruteforce methode zou exact dezelfde data moeten opleveren. En is buiten proporsie, en daarom geen persoonsgegeven. Het zou mij *zeer* interessant lijken om dit soort kaarten te maken voor meerdere ziekten. Stefan -- Forwarded message -- Date: Tue, 29 Jul 2008 10:49:08 +0200 From: CBP - Info [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Kenmerk: e2008-01832 Den Haag, 29 juli 2008 Geachte heer De Konink, U heeft het College bescherming persoonsgegevens (CBP) in het kader van de onderstaande situatie gevraagd of een postcode een persoon identificeerbaar maakt. Uw organisatie wil een aantal thema kaarten maken die het aantal patiënten dat lijdt aan een specifieke aandoening op straat en/of wijk niveau gaan visualiseren en te correleren met andere data bronnen op uw kaart. U geeft hierbij aan dat het gaat om; * 4 of 6 positie postcodes * Aantal gevallen van kankertype per postcode. Herleidbaar van persoonsgegevens De Wet bescherming persoonsgegevens (Wbp) verstaat onder een persoonsgegeven: elk gegeven betreffende een geïdentificeerde of identificeerbare natuurlijke persoon (artikel 1, sub a, Wbp). Ten eerste moet het gaan om informatie betreffende een natuurlijk persoon, ten tweede moet deze persoon geïdentificeerd of althans identificeerbaar zijn. Als aan één van beide elementen niet is voldaan, dan is geen sprake van een persoonsgegeven. Daarnaast zijn de mogelijkheden van de verantwoordelijke en de ontvanger om een betrokkene te identificeren bepalend voor de vraag of sprake is van persoonsgegevens. Indien de gegevens niet direct tot identificatie van een bepaald persoon leiden maar wel via nadere stappen in verband kunnen worden gebracht met een bepaalde persoon, is sprake van indirect identificerende gegevens. Dit is het geval, indien gegevens niet direct op naam zijn terug te vinden, maar de betrokken persoon met aanwending van de beschikbare middelen alsnog kan worden achterhaald, bijvoorbeeld aan de hand van een nummer. Ook valt te denken aan situaties, waarin een bijzondere eigenschap of combinatie van eigenschappen hetzij direct, hetzij door koppeling of vergelijking met andere beschikbare informatie identificatie van een persoon mogelijk maakt. Een combinatie van ziekte en straatnaam is doorgaans identificerend zijn, ook als de identiteit van betrokkene niet meteen vermeld wordt. Mogelijkheden van de verantwoordelijke en de ontvanger om te identificeren Voor de vraag of sprake is van identificeerbaarheid is mede van belang over welke mogelijkheden de verantwoordelijke en de ontvanger beschikken tot identificatie, evenals de bekendheid met of beschikbaarheid van aanvullende informatie. Uitgangspunt is een redelijk toegeruste verantwoordelijke/ontvanger. In concrete gevallen moet echter wel rekening gehouden worden met bijzondere expertise, technische faciliteiten en dergelijke van de verantwoordelijke. Indien de identiteit van een persoon niet of slechts met een disproportionele aanwending van geld, menskracht of middelen kan worden achterhaald, is geen sprake van een persoonsgegeven in de zin van de Wbp. Dit is bijvoorbeeld het geval indien identificatie door de computer vele dagen in beslag zou nemen. In die situatie dient er redelijkerwijs van te worden uitgegaan dat identificatie niet zal plaatsvinden en de wet derhalve niet van toepassing is. Ook is dat het geval, indien het risico van identificatie door middel van spontane herkenning redelijkerwijs is uitgesloten (het risico hoeft niet absoluut te worden uitgesloten). Persoonsgegevens Indien u naar aanleiding van de bovenstaande informatie van mening bent dat u persoonsgegevens verwerkt gelden de volgende bepalingen. U moet de verwerking van persoonsgegevens kunnen baseren op één van de zes in artikel 8 Wbp genoemde grondslagen. Het is bijvoorbeeld toegestaan persoonsgegevens te verwerken als het noodzakelijk is voor de uitvoering van een overeenkomst (artikel 8, onderdeel b, Wbp). Meer informatie over dit onderwerp vindt u het informatieblad 'Verstrekken van persoonsgegevens'. Daarnaast kent de Wbp een strikt regime voor het verwerken (waaronder verzamelen en verspreiden) van bijzondere gegevens, zoals gezondheidsgegevens. Verwerking van bijzondere gegevens is in beginsel verboden op grond van artikel 16 Wbp, behoudens de artikelen 17 tot en met 23 Wbp genoemde uitzonderingen. Voor gezondheidsgegevens zijn de artikelen 21 en 23 Wbp van belang. Het begrip gezondheidsgegeven heeft betrekking
[OSM-talk-nl] Huisnummers AND in Karlsruhe formaat
Hoi, Op [EMAIL PROTECTED] woedt alweer de zoveelste discussie over huisnummer-schema's [1], en wij zitten nog steeds met onze data van AND [2]. Omdat het mij leek dat het Karlsruhe schema [3] de grootste kans op succes (=gebruik) heeft, ben ik begonnen het AND conversie tool aan te passen om huisnummers uit te schrijven in dit formaat. Een eerste resultaat is hier te vinden: http://www.vanwal.nl/osm/huisnummers_AND_Eindhoven.osm (Deel van het centrum en noorden van Eindhoven, alleen huisnummers, andere data kan je er met JOSM zelf overheen laden. Als je graag een ander gebied ziet genereer ik die zo, gegeven een bounding box.) Het grote voordeel van dit formaat voor ons (osm-nl) is dat de conversie onafhankelijk van de eerder geimporteerde data gegenereerd en geupload kan worden. Voor nadelen, zie o.a. de thread op talk [2]. Het belangrijkste nadeel voor de Nederlandse situatie lijkt me de hoeveelheid data: elke weg met huizen aan beide kanten zorgt voor twee nieuwe ways (om een indicatie te geven: heel Nederland genereerd een .osm-file van zo'n 300 a 400 MB). In mijn huidige versie wordt dan ook de naam van de straat (addr:street) en het AND_nosr_r veld herhaalt om de adressen later met de juiste weg te kunnen koppelen. Een alternatief zou zijn om relaties te gebruiken, maar dat zou nog meer data genereren, dus dat heb ik nog maar niet gedaan. Details van de conversie De huidige implementatie verschuift de nodes van een weg met huisnummers naar links of rechts over een voorgedefinieerde afstand (op dit moment kan maar één van die twee gekozen worden, ik draai het tool twee keer en voeg de data samen). De weg wordt niet als geheel verplaatst (dat zou rare resultaten geven bij kronkelenende wegen), maar elke node op zich wordt verplaatst in de richting van de normaal op de hoek waar die node zit. Dit resulteert in netjes geëxplodeerde en geïmplodeerde wegen. Daarna wordt de weg aan beide uiteinden nog een beetje ingekort (weer met een vaste afstand) omdat dat in de meeste gevallen een resultaat geeft dat het meeste met de werkelijkheid overeen komt. Problemen/Hoe verder? De huidige implementatie is niet perfect (en de gegenereerde data zal altijd nabewerking vergen), maar zoals je in bovenstaand voorbeeld kan zien ziet het er in de meeste gevallen al best aardig uit. Dingen die ik eventueel nog zou aanpassen als we echt met deze data willen gaan werken zijn - simplificatie van de gegenereerde huisnummer-ways om de hoeveelheid nutteloze nodes een beetje in de perken te houden, - verfijning van de gegenereerde tags (addr:range_odd en addr:range_even kunnen weg, AND_nosr_r moet misschien ook geprefixt worden, etc.). Verder denk ik dat een eventuele import op twee manieren gedaan zou kunnen worden: - Big bang, alles in één keer zoals met de originele AND import. Nadeel hiervan is dat het op sommige plaatsen misschien een beetje een rotzooitje kan worden door bijv. slechte conversie of bestaande data die is aangepast en de huisnummers niet meer netjes langs de straten lopen. - Stuksgewijs, waarbij iedereen een gebiedje kan downloaden, bekijken, aanpassen en dan uploaden. Voordelen en nadelen worden als oefening voor de lezer gelaten ;-) P.S. Ik wil hier best in Veenendaal of Baarn (maar dat duurt weer zo lang) met mensen over doorpraten, laat het even weten als je dat een goed idee lijkt. [1] Begonnen met http://lists.openstreetmap.org/pipermail/talk/2008-July/028151.html [2] http://wiki.openstreetmap.org/index.php/AND_Data/Spec#Roads_file (zie RD_23, hn#...) [3] http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers/Karlsruhe_Schema -- Freek ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Huisnummers AND in Karlsruhe formaat
On Tue, 29 Jul 2008, Freek wrote: Een alternatief zou zijn om relaties te gebruiken, maar dat zou nog meer data genereren, dus dat heb ik nog maar niet gedaan. Dat meer data genereren maakt niet uit, immers je gaat alleen relaties gebruiken als je daadwerkelijk wat met huisnummers gaat doen (toch?!). Voor 80% van de zoomlevels zijn huisnummers niet relevant, waarom het dan toch als tags willen meegeven? Details van de conversie De huidige implementatie verschuift de nodes van een weg met huisnummers naar links of rechts over een voorgedefinieerde afstand (op dit moment kan maar één van die twee gekozen worden, ik draai het tool twee keer en voeg de data samen). De weg wordt niet als geheel verplaatst (dat zou rare resultaten geven bij kronkelenende wegen), maar elke node op zich wordt verplaatst in de richting van de normaal op de hoek waar die node zit. Dit resulteert in netjes geëxplodeerde en geïmplodeerde wegen. Daarna wordt de weg aan beide uiteinden nog een beetje ingekort (weer met een vaste afstand) omdat dat in de meeste gevallen een resultaat geeft dat het meeste met de werkelijkheid overeen komt. Bedoel je dat er een kopie van het straten plan wordt gemaakt en een 'blevel' op wordt toegepast? Als er een tooltje is om straks 'taken' te delegeren zou dat wel een voordeel zijn, als het er niet is, jammer maar helaas zal het dan toch were een big bang worden. Ik maak me alleen een beetje zorgen over routering en het data duplicatio beleid. Buiten dat er twee extra 'wegen' bij komen, wordt ook de straatnaam gedupliceerd. Zelf zie ik momenteel het voordeel niet in om data op dit niveau te dupliceren. Als dat wel het algemene beeld is zou je *JUIST* weer terug willen naar relations. Zodat je niet postcode, straatnaam, etc. dubbel gaat neerzetten. Het materaliseren van de straatnaam in wegen en in deze reeksen zal wel uit het oogpunt van 'makkelijk' zijn voortgekomen, 'nodig' is het niet. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Huisnummers AND in Karlsruhe formaat
mooi wark! ik ga vanavond eens kijken hoe goed de data is. het viel me wel op dat er ranges zijn van 1 huisnummer, bv: tag k='addr:range_even' v='4-4' / misschien kun je die nog naar een huisnummer node omzetten? of ze misschien negeren want ik zie dat sommige hiervan wel uit meerdere nodes bestaan? stefan z'n opmerking over duplicatie deel ik, de straatnamen hoeven er eigenlijk alleen in als er onduidelijkheid zou kunnen optreden? groet, floris Freek schreef: Hoi, Op [EMAIL PROTECTED] woedt alweer de zoveelste discussie over huisnummer-schema's [1], en wij zitten nog steeds met onze data van AND [2]. Omdat het mij leek dat het Karlsruhe schema [3] de grootste kans op succes (=gebruik) heeft, ben ik begonnen het AND conversie tool aan te passen om huisnummers uit te schrijven in dit formaat. Een eerste resultaat is hier te vinden: http://www.vanwal.nl/osm/huisnummers_AND_Eindhoven.osm (Deel van het centrum en noorden van Eindhoven, alleen huisnummers, andere data kan je er met JOSM zelf overheen laden. Als je graag een ander gebied ziet genereer ik die zo, gegeven een bounding box.) Het grote voordeel van dit formaat voor ons (osm-nl) is dat de conversie onafhankelijk van de eerder geimporteerde data gegenereerd en geupload kan worden. Voor nadelen, zie o.a. de thread op talk [2]. Het belangrijkste nadeel voor de Nederlandse situatie lijkt me de hoeveelheid data: elke weg met huizen aan beide kanten zorgt voor twee nieuwe ways (om een indicatie te geven: heel Nederland genereerd een .osm-file van zo'n 300 a 400 MB). In mijn huidige versie wordt dan ook de naam van de straat (addr:street) en het AND_nosr_r veld herhaalt om de adressen later met de juiste weg te kunnen koppelen. Een alternatief zou zijn om relaties te gebruiken, maar dat zou nog meer data genereren, dus dat heb ik nog maar niet gedaan. Details van de conversie De huidige implementatie verschuift de nodes van een weg met huisnummers naar links of rechts over een voorgedefinieerde afstand (op dit moment kan maar één van die twee gekozen worden, ik draai het tool twee keer en voeg de data samen). De weg wordt niet als geheel verplaatst (dat zou rare resultaten geven bij kronkelenende wegen), maar elke node op zich wordt verplaatst in de richting van de normaal op de hoek waar die node zit. Dit resulteert in netjes geëxplodeerde en geïmplodeerde wegen. Daarna wordt de weg aan beide uiteinden nog een beetje ingekort (weer met een vaste afstand) omdat dat in de meeste gevallen een resultaat geeft dat het meeste met de werkelijkheid overeen komt. Problemen/Hoe verder? De huidige implementatie is niet perfect (en de gegenereerde data zal altijd nabewerking vergen), maar zoals je in bovenstaand voorbeeld kan zien ziet het er in de meeste gevallen al best aardig uit. Dingen die ik eventueel nog zou aanpassen als we echt met deze data willen gaan werken zijn - simplificatie van de gegenereerde huisnummer-ways om de hoeveelheid nutteloze nodes een beetje in de perken te houden, - verfijning van de gegenereerde tags (addr:range_odd en addr:range_even kunnen weg, AND_nosr_r moet misschien ook geprefixt worden, etc.). Verder denk ik dat een eventuele import op twee manieren gedaan zou kunnen worden: - Big bang, alles in één keer zoals met de originele AND import. Nadeel hiervan is dat het op sommige plaatsen misschien een beetje een rotzooitje kan worden door bijv. slechte conversie of bestaande data die is aangepast en de huisnummers niet meer netjes langs de straten lopen. - Stuksgewijs, waarbij iedereen een gebiedje kan downloaden, bekijken, aanpassen en dan uploaden. Voordelen en nadelen worden als oefening voor de lezer gelaten ;-) P.S. Ik wil hier best in Veenendaal of Baarn (maar dat duurt weer zo lang) met mensen over doorpraten, laat het even weten als je dat een goed idee lijkt. [1] Begonnen met http://lists.openstreetmap.org/pipermail/talk/2008-July/028151.html [2] http://wiki.openstreetmap.org/index.php/AND_Data/Spec#Roads_file (zie RD_23, hn#...) [3] http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers/Karlsruhe_Schema -- Freek ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Huisnummers AND in Karlsruhe formaat
On Tuesday 29 July 2008, Stefan de Konink wrote:
On Tue, 29 Jul 2008, Freek wrote:
Een alternatief zou zijn om relaties te gebruiken, maar dat zou nog
meer data genereren, dus dat heb ik nog maar niet gedaan.
Ik bedoel hier: alternatief voor het toevoegen van addr:street en AND_nosr_r,
dus een relatie maken met daarin tenminste de straat zelf en de
huisnummer-ways aan beide kanten als members. Zoiets als dit dus (van de wiki
gekopieerd):
relation id=??
tag k=type v=associatedStreet /
member type=way ref=11 role=house /
member type=way ref=??? role=street /
/relation
Dat meer data genereren maakt niet uit, immers je gaat alleen relaties
gebruiken als je daadwerkelijk wat met huisnummers gaat doen (toch?!).
Huidige tools (tenminste JOSM, dus de map-API doet dit volgens mij)
downloaden gewoon alle relaties van elementen binnen de opgevraagde bounding
box, dat zou dus in stedelijke gebieden een enorme berg (in de meeste
gevallen nutteloze) huisnummer-relaties meenemen die je relatie-window
vullen. Ok, editor support moet gewoon beter, dan zijn we daar vanaf. Het is
danook geen argument om nooit relaties te gaan gebruiken, alleen nu nog even
niet. Voor een eventuele import moeten we gewoon samen bepalen of we relaties
willen of niet (en andere details), en die dan implementeren (enige probleem
is dan nog het terugvinden van bestaande wegen, gegeven AND_nosr_r's, maar
goed).
Voor 80% van de zoomlevels zijn huisnummers niet relevant, waarom het dan
toch als tags willen meegeven?
Ehm, wat bedoel je hier?
Details van de conversie
De huidige implementatie verschuift de nodes van een weg met huisnummers
naar links of rechts over een voorgedefinieerde afstand [...]
Bedoel je dat er een kopie van het straten plan wordt gemaakt
Ja.
en een 'blevel' op wordt toegepast?
Ik weet niet wat een 'blevel' is ('bevel'?, dan nog snap blijft het vaag),
maar kijk gewoon even in de .osm van het vorige mailtje.
Als er een tooltje is om straks 'taken' te delegeren zou dat wel een
voordeel zijn, als het er niet is, jammer maar helaas zal het dan toch
were een big bang worden.
Wiki? Zo gebeurd het in veel andere landen.
Ik maak me alleen een beetje zorgen over routering
Routering zie ik als volgt:
- Voorwerk: maak een index op addr:street
- Query straat nummer:
- zoek straat in de index, dit geeft een lijst huisnummer-ways;
- zoek nummer binnen deze lijst wegen (die hopelijk niet al te groot is,
anders kan je de index daar wel voor uitbreiden);
- gebruik interpolatie om lat,lon te vinden voor het adres;
- pas een al bestaande implementatie toe om van een lat,lon combinatie
de dichtstbijzijnde weg en punt daarop te vinden;
- routeer naar het gevonden punt op de weg.
en het data duplicatio
beleid. Buiten dat er twee extra 'wegen' bij komen, wordt ook de
straatnaam gedupliceerd. Zelf zie ik momenteel het voordeel niet in om
data op dit niveau te dupliceren.
Helemaal gelijk in, daarvoor zouden relaties inderdaad kunnen werken. Aan de
andere kant denk ik: die straatnamen worden nu toch al tig keer gedupliceerd
(voor alle losse weg-delen), dus jammer dan van die paar extra... Later zou
je toch misschien weer super-way-relaties willen hebben, met alle wegdelen en
huisnummer-ways bij elkaar.
--
Freek
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Huisnummers AND in Karlsruhe formaat
Ik vind het hele huisnummer verhaal een behoorlijk zinloze discussie. Laten we eerst maar eens zorgen dat we zeker weten dat we alle straten en fietspaden van nederland er goed in hebben zitten, en dat de kaart correct routeerd, dan kunnen we daarna de blinde apen die zelf het huisnummer niet kunnen vinden gaan helpen. Postcode vind ik nog wel nuttig, op kleine apparaten kan dat makkelijker in te toetsen zijn dan een straatnaam. Mijn idee voor huisnummers was om een straat in te delen in segmenten, en deze een tag te geven waarin je aangeeft welke huisnummers aan dat segment liggen. In een woonwijk geeft dat genoeg precisie. Of het nummer dan links of rechts aan de weg zit vind ik vrij nutteloze informatie. In 50% van de gevallen staat er maar aan 1 kant van de weg huizen. Aan een landelijke weg, waar slechts om de zoveel honderd meter een woning staat, map ik de oprijlaan als highway=service en voeg daar de straatnaam en huisnummer in een tag aan toe. Tijdens het routeren naar zo'n adres krijg je dan netjes een melding over 100 meter rechtsaf waarna je mooi de oprijlaan van het gezochte adres oprijdt. Het lijkt me goed om hier in Veenendaal over te praten. Geert Schuring. - Original Message From: OpenStreetMap NL discussion list talk-nl@openstreetmap.org To: OpenStreetMap NL discussion list talk-nl@openstreetmap.org Subject: [OSM-talk-nl] Huisnummers AND in Karlsruhe formaat Date: 29/07/08 12:23 Hoi, Op [EMAIL PROTECTED] woedt alweer de zoveelste discussie over huisnummer-schema's [1], en wij zitten nog steeds met onze data van AND [2]. Omdat het mij leek dat het Karlsruhe schema [3] de grootste kans op succes (=gebruik) heeft, ben ik begonnen het AND conversie tool aan te passen om huisnummers uit te schrijven in dit formaat. Een eerste resultaat is hier te vinden: http://www.vanwal.nl/osm/huisnummers_AND_Eindhoven.osm (Deel van het centrum en noorden van Eindhoven, alleen huisnummers, andere data kan je er met JOSM zelf overheen laden. Als je graag een ander gebied ziet genereer ik die zo, gegeven een bounding box.) Het grote voordeel van dit formaat voor ons (osm-nl) is dat de conversie onafhankelijk van de eerder geimporteerde data gegenereerd en geupload kan worden. Voor nadelen, zie o.a. de thread op talk [2]. Het belangrijkste nadeel voor de Nederlandse situatie lijkt me de hoeveelheid data: elke weg met huizen aan beide kanten zorgt voor twee nieuwe ways (om een indicatie te geven: heel Nederland genereerd een .osm-file van zo'n 300 a 400 MB). In mijn huidige versie wordt dan ook de naam van de straat (addr:street) en het AND_nosr_r veld herhaalt om de adressen later met de juiste weg te kunnen koppelen. Een alternatief zou zijn om relaties te gebruiken, maar dat zou nog meer data genereren, dus dat heb ik nog maar niet gedaan. Details van de conversie De huidige implementatie verschuift de nodes van een weg met huisnummers naar links of rechts over een voorgedefinieerde afstand (op dit moment kan maar één van die twee gekozen worden, ik draai het tool twee keer en voeg de data samen). De weg wordt niet als geheel verplaatst (dat zou rare resultaten geven bij kronkelenende wegen), maar elke node op zich wordt verplaatst in de richting van de normaal op de hoek waar die node zit. Dit resulteert in netjes quot;geëxplodeerdequot; en quot;geïmplodeerdequot; wegen. Daarna wordt de weg aan beide uiteinden nog een beetje ingekort (weer met een vaste afstand) omdat dat in de meeste gevallen een resultaat geeft dat het meeste met de werkelijkheid overeen komt. Problemen/Hoe verder? De huidige implementatie is niet perfect (en de gegenereerde data zal altijd nabewerking vergen), maar zoals je in bovenstaand voorbeeld kan zien ziet het er in de meeste gevallen al best aardig uit. Dingen die ik eventueel nog zou aanpassen als we echt met deze data willen gaan werken zijn - simplificatie van de gegenereerde huisnummer-ways om de hoeveelheid nutteloze nodes een beetje in de perken te houden, - verfijning van de gegenereerde tags (addr:range_odd en addr:range_even kunnen weg, AND_nosr_r moet misschien ook geprefixt worden, etc.). Verder denk ik dat een eventuele import op twee manieren gedaan zou kunnen worden: - Big bang, alles in één keer zoals met de originele AND import. Nadeel hiervan is dat het op sommige plaatsen misschien een beetje een rotzooitje kan worden door bijv. slechte conversie of bestaande data die is aangepast en de huisnummers niet meer netjes langs de straten lopen. - Stuksgewijs, waarbij iedereen een gebiedje kan downloaden, bekijken, aanpassen en dan uploaden. Voordelen en nadelen worden als oefening voor de lezer gelaten ;-) P.S. Ik wil hier best in Veenendaal of Baarn (maar dat duurt weer zo lang) met mensen over doorpraten, laat het even weten als je dat een goed idee lijkt. [1] Begonnen met
Re: [OSM-talk-nl] Huisnummers AND in Karlsruhe formaat
On Tuesday 29 July 2008, Floris Looijesteijn wrote: mooi wark! ik ga vanavond eens kijken hoe goed de data is. Dank. Bij mij in de buurt is de data niet perfect (soms lijkt de data een beetje in het formaat geperst, terwijl dat in het Karlsruhe schema mooier kan, bijvoorbeeld in het geval van losstaande huizen), maar zeker de moeite van het importeren waard als je het ziet als de eerste stap naar per-huis huisnummer en positie (zie [1] voor meer uitleg van die visie). het viel me wel op dat er ranges zijn van 1 huisnummer, bv: tag k='addr:range_even' v='4-4' / misschien kun je die nog naar een huisnummer node omzetten? of ze misschien negeren want ik zie dat sommige hiervan wel uit meerdere nodes bestaan? Goed gezien, vergeten te noemen. Die wil ik inderdaad naar een node omzetten in het midden van de verschoven weg. stefan z'n opmerking over duplicatie deel ik, de straatnamen hoeven er eigenlijk alleen in als er onduidelijkheid zou kunnen optreden? Dat AND_nosr_r-veld is eigenlijk nog specifieker en maakt addr:street in zekere zin overbodig, maar goed die willen we niet als enige houden denk ik. Zie verder ook mijn reactie op Stefan's mail, ik ben niet tegen relaties, maar daar kleven ook wel wat problemen aan. Klopt het dat jij nog als alternatief voorsteld om alleen straatnamen op te nemen als er onduidelijkheid kan ontstaan, zo ja, wanneer is een koppeling onduidelijk (even afgezien van AND_nosr_r)? Nog iets, voordat iemand anders erover begint ;-), bij sommige scherpe hoeken zijn de huisnummer-ways in de binnenhoek zelf-snijdend. Dat wil ik ook nog wel gaan oplossen, maar (net als de rest van de aanpassingen), graag pas nadat er enige zekerheid is dat het gebruikt gaat worden. [1] http://lists.openstreetmap.org/pipermail/talk/2008-July/028274.html -- Freek ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Huisnummers AND in Karlsruhe formaat
On Tuesday 29 July 2008, Geert Schuring wrote: Ik vind het hele huisnummer verhaal een behoorlijk zinloze discussie. Laten we eerst maar eens zorgen dat we zeker weten dat we alle straten en fietspaden van nederland er goed in hebben zitten, en dat de kaart correct routeerd, Eén van de redenen waarom ik met deze conversie begonnen ben is omdat mijn dorp al een tijd klaar is tot op dat nivo. Dan kan ik drie dingen doen: - Stoppen. - Steden en dorpen in de buurt verbeteren, daar ben ik ook mee bezig. - Meer detail toevoegen. Dan kom je al vrij snel bij gebouwen en de daaraan gekoppelde nummers. Ik kan natuurlijk te voet alles nog een keer doen en overal die nummers noteren, maar de informatie bestaat gewoon al, waarom zouden we die niet gebruiken? Postcode vind ik nog wel nuttig, op kleine apparaten kan dat makkelijker in te toetsen zijn dan een straatnaam. We hebben nodes voor het numerieke deel van de postcode, m.i. nutteloos voor routering. Met letters erbij wordt het wel nuttig, maar daar heb je hetzelfde links/rechts probleem als bij huisnummers. Het Karlsruhe schema maakt het mogelijk postcodes op de juiste plek toe te voegen: bij de rij huizen waar de postcode bij hoort. Mijn idee voor huisnummers was om een straat in te delen in segmenten, en deze een tag te geven waarin je aangeeft welke huisnummers aan dat segment liggen. Ik heb ze niet doorgelezen, maar zoiets zal hier best wel ergens tussen te vinden zijn: http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers In een woonwijk geeft dat genoeg precisie. Of het nummer dan links of rechts aan de weg zit vind ik vrij nutteloze informatie. Dat idee heb ik nog niet eerder gehoord, en ik zou me er best in kunnen vinden, behalve dat we de informatie gewoon al hebben en dat er genoeg mensen zijn die het wel handig vinden. In 50% van de gevallen staat er maar aan 1 kant van de weg huizen. Aan een landelijke weg, waar slechts om de zoveel honderd meter een woning staat, map ik de oprijlaan als highway=service en voeg daar de straatnaam en huisnummer in een tag aan toe. Voor de huizen die zo gemapt zijn lijkt het me een zeer goede oplossing, maar niet ieder landelijk gelegen huis heeft zo'n oprijlaan en niet iedere OSM'er heeft zin om die te mappen (laat staan of ze in de AND data zitten). Het lijkt me goed om hier in Veenendaal over te praten. Ok, beschouw me hierbij als aangemeld ;-) Is er nog een plaats in een auto beschikbaar die station Utrecht of Veenendaal aan doet? -- Freek ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Huisnummers AND in Karlsruhe formaat
Ok, beschouw me hierbij als aangemeld ;-) Is er nog een plaats in een auto beschikbaar die station Utrecht of Veenendaal aan doet? Ik ga zeker met de auto en ging toch al langs utrecht cs om kleptog op te halen daar (als-ie wat van zich laat horen tenminste). Je kunt dan met mij meerijden en savonds terug naar Utrecht. -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Huisnummers AND in Karlsruhe formaat
On Tuesday 29 July 2008, Martijn van Exel wrote: Ok, beschouw me hierbij als aangemeld ;-) Is er nog een plaats in een auto beschikbaar die station Utrecht of Veenendaal aan doet? Ik ga zeker met de auto en ging toch al langs utrecht cs om kleptog op te halen daar (als-ie wat van zich laat horen tenminste). Je kunt dan met mij meerijden en savonds terug naar Utrecht. Graag, dank je. Treinen naar Utrecht rijden elk kwartier, dus als je met kleptog een tijd afspreekt is het goed wat mij betreft. -- Freek ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Huisnummers AND in Karlsruhe formaat
On Tue, 29 Jul 2008, Freek wrote: Voor 80% van de zoomlevels zijn huisnummers niet relevant, waarom het dan toch als tags willen meegeven? Ehm, wat bedoel je hier? Als je huisnummers met apparte nodes gaat modelleren en daar de addr: prefix bij de tag voorzet, wordt bij een willekeurige map request toch ook alle nodes gedownload? Als er een tooltje is om straks 'taken' te delegeren zou dat wel een voordeel zijn, als het er niet is, jammer maar helaas zal het dan toch were een big bang worden. Wiki? Zo gebeurd het in veel andere landen. Wiki is iets om informatie in op te slaan, per definitie niet de optimale tool om taken te delegeren. Niet optimaler dan een willekeurig stukje papier. en het data duplicatio beleid. Buiten dat er twee extra 'wegen' bij komen, wordt ook de straatnaam gedupliceerd. Zelf zie ik momenteel het voordeel niet in om data op dit niveau te dupliceren. Helemaal gelijk in, daarvoor zouden relaties inderdaad kunnen werken. Aan de andere kant denk ik: die straatnamen worden nu toch al tig keer gedupliceerd (voor alle losse weg-delen), dus jammer dan van die paar extra... Later zou je toch misschien weer super-way-relaties willen hebben, met alle wegdelen en huisnummer-ways bij elkaar. Daar ben *ik* ook niet blij mee ;) maar zonder dat we in een discussie verzanden om een beter data model te maken, voorkomen is beter dan (alles) genezen. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
