Re: [OSM-talk-be] Validatie foutmelding: Onbenoemde wegen maar verbindings- voetpad heeft geen naam

[Sander Deryckere]

Footway or path (als er ook over gefietst wordt) zijn beter in dit geval.

Pedestrian is idd voor brede, voetgangersstraten. Dus bij pedestrian wordt
een naam verwacht, bij footway niet.

Groeten,
Sander

Op 25 oktober 2014 21:55 schreef Jakka :

> Jakka schreef op 25/10/2014 om 21:29:
>
>  Sander Deryckere schreef op 25/10/2014 om 21:19:
>>
>>> Bij mijn weten geeft JOSM geen validatieproblemen als je een footway,
>>> cycleway, track of path hebt zonder naam.
>>>
>>> Over welke weg gaat het juist, en met welke editor werk je?
>>>
>>> Groeten,
>>> Sander
>>>
>>> Op 25 oktober 2014 20:56 schreef Jakka
>>> >> >:
>>>
>>> Dag,
>>>
>>> Welke "name" tag dient om een naamloos pad of veldweg of
>>> verbindings- weg te geven zodanig dat de validatie geen foutmelding
>>> vertoont.
>>> De noname=yes helpt niet
>>>
>>> http://wiki.openstreetmap.org/__wiki/Names#No_name
>>> 
>>>
>>> Hier kom ik niet uit (vermoedelijk voorstel?)
>>>
>>> http://wiki.openstreetmap.org/__wiki/Proposed_features/
>>> Noname#__T:absent_.3D_yes
>>>
>>>
>>> >> Noname#T:absent_.3D_yes>
>>>
>>>
>>> Jakka
>>>
>>>
>>> _
>>> 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
>>>
>>>  @Sander,
>>
>> editor josm
>>
>> Hugo Verrieststraat naar parking de verbindingen via parking zijn nog
>> niet zichtbaar, maar wel al aangepast. Deze waren compleet fout, gingen
>> door omheining.
>> http://www.openstreetmap.org/?mlat=50.78955&mlon=3.19695#
>> map=19/50.78955/3.19695&layers=N
>>
>>
>> Eerste maal dat ik link toevoeg hopelijk heb je er iets aan.
>>
>>  gebruik variant van highway=footway
>
> http://wiki.openstreetmap.org/wiki/Map_Features?setlang=nl
>
>  Use highway=pedestrian for pedestrianised roads in shopping or
> residential areas and highway=track if it is usable by agricultural or
> similar vehicles.
>
>
> Jakka
>
>
>
> ___
> 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

Re: [OSM-talk-be] Validatie foutmelding: Onbenoemde wegen maar verbindings- voetpad heeft geen naam

[Jakka]

Jakka schreef op 25/10/2014 om 21:29:

Sander Deryckere schreef op 25/10/2014 om 21:19:

Bij mijn weten geeft JOSM geen validatieproblemen als je een footway,
cycleway, track of path hebt zonder naam.

Over welke weg gaat het juist, en met welke editor werk je?

Groeten,
Sander

Op 25 oktober 2014 20:56 schreef Jakka
mailto:vdmfrank...@gmail.com>>:

Dag,

Welke "name" tag dient om een naamloos pad of veldweg of
verbindings- weg te geven zodanig dat de validatie geen foutmelding
vertoont.
De noname=yes helpt niet

http://wiki.openstreetmap.org/__wiki/Names#No_name


Hier kom ik niet uit (vermoedelijk voorstel?)

http://wiki.openstreetmap.org/__wiki/Proposed_features/Noname#__T:absent_.3D_yes





Jakka


_
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


@Sander,

editor josm

Hugo Verrieststraat naar parking de verbindingen via parking zijn nog
niet zichtbaar, maar wel al aangepast. Deze waren compleet fout, gingen
door omheining.
http://www.openstreetmap.org/?mlat=50.78955&mlon=3.19695#map=19/50.78955/3.19695&layers=N


Eerste maal dat ik link toevoeg hopelijk heb je er iets aan.


gebruik variant van highway=footway

http://wiki.openstreetmap.org/wiki/Map_Features?setlang=nl

 Use highway=pedestrian for pedestrianised roads in shopping or 
residential areas and highway=track if it is usable by agricultural or 
similar vehicles.


Jakka



___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Validatie foutmelding: Onbenoemde wegen maar verbindings- voetpad heeft geen naam

[Jakka]

Sander Deryckere schreef op 25/10/2014 om 21:19:

Bij mijn weten geeft JOSM geen validatieproblemen als je een footway,
cycleway, track of path hebt zonder naam.

Over welke weg gaat het juist, en met welke editor werk je?

Groeten,
Sander

Op 25 oktober 2014 20:56 schreef Jakka
mailto:vdmfrank...@gmail.com>>:

Dag,

Welke "name" tag dient om een naamloos pad of veldweg of
verbindings- weg te geven zodanig dat de validatie geen foutmelding
vertoont.
De noname=yes helpt niet

http://wiki.openstreetmap.org/__wiki/Names#No_name


Hier kom ik niet uit (vermoedelijk voorstel?)

http://wiki.openstreetmap.org/__wiki/Proposed_features/Noname#__T:absent_.3D_yes



Jakka


_
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


@Sander,

editor josm

Hugo Verrieststraat naar parking de verbindingen via parking zijn nog 
niet zichtbaar, maar wel al aangepast. Deze waren compleet fout, gingen 
door omheining.

http://www.openstreetmap.org/?mlat=50.78955&mlon=3.19695#map=19/50.78955/3.19695&layers=N

Eerste maal dat ik link toevoeg hopelijk heb je er iets aan.

Jakka


___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Validatie foutmelding: Onbenoemde wegen maar verbindings- voetpad heeft geen naam

[Sander Deryckere]

Bij mijn weten geeft JOSM geen validatieproblemen als je een footway,
cycleway, track of path hebt zonder naam.

Over welke weg gaat het juist, en met welke editor werk je?

Groeten,
Sander

Op 25 oktober 2014 20:56 schreef Jakka :

> Dag,
>
> Welke "name" tag dient om een naamloos pad of veldweg of verbindings- weg
> te geven zodanig dat de validatie geen foutmelding vertoont.
> De noname=yes helpt niet
>
> http://wiki.openstreetmap.org/wiki/Names#No_name
>
> Hier kom ik niet uit (vermoedelijk voorstel?)
> http://wiki.openstreetmap.org/wiki/Proposed_features/Noname#
> T:absent_.3D_yes
>
> Jakka
>
>
> ___
> 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

Re: [OSM-talk-be] import AGIV CRAB-data

[Sander Deryckere]

Op 25 oktober 2014 20:57 schreef Thomas :

>
> Inmiddels ook de codering in gehoorzaamheid gedwongen. Blijkt dat de
> codering van de shapefile gewoon Latin-1 is en niet die vage CP-720. Dat
> scheelt ook maar weer.
>
> De snelheid van mijn script valt me al bij al wel mee. Op dit moment
> gebruikt hij maar 1 thread. Het inlezen van het bestand in de dictionaries
> duurt zo'n 50 minuten. Het schrijven naar de JSON-bestanden een kleine 10
> minuten (op een SSD'tje). Het schrijven gaat volgens mij wat trager omdat
> ik de adres-dictionary vervangen heb door een tuple. Dat scheelt toch een
> kleine 500MB in geheugengebruik. In totaal gebruikt het script maar iets
> van 2GB ram dacht ik, maar dat moet ik nog even nakijken. Sinds die
> wijziging heb ik in elk geval geen geheugenproblemen meer gehad.
>
> Qua tags hoeven we inderdaad enkel de addr:housenumber en addr:street over
> te nemen. Daarnaast wil ik graag het herkomst-veld als tag invoeren, zodat
> de punten gestyled kunnen worden op basis daarvan. Naar mijn idee is die
> herkomst zeer bepalend voor de “nauwkeurigheid” van de punten. Ik heb dat
> nu geïmplementeerd als een “CRAB:herkomst”-tag. De Engelse variant
> “CRAB:source” vond ik een beetje misleidend. Aan de andere kant gaat het
> natuurlijk wel over hoe ze de locatie van het punt bepaald hebben. Dat kun
> je dus wel als “source” zien.
>

CRAB:source=* lijkt me goed. Als de waarden enigszins duidelijk zijn, dan
is alles ok.

>
> Daarnaast misschien nog iets van een tag om waarschuwingen mee te
> communiceren, bijvoorbeeld over de schrijfwijze van de straatnaam. Aan de
> andere kant heb ik geen enkel geval kunnen vinden waar twee adressen een
> zelfde straatnaam-id hebben maar een verschillende straatnaam (bijvoorbeeld
> een andere spelling). Dat soort fouten lijken me maar beperkt aanwezig en
> kunnen dus waarschijnlijk allemaal opgevangen worden met de FIXME-tag. Het
> huidige gebruik (om punten zonder locatie mee aan te geven) is in feite
> overbodig, omdat alle punten een locatie hebben.
>
> De JOSM validator kan hier ook nuttig zijn. Als de coordinaten volledig
overeenkomen, dan zal de validator sowieso klagen denk ik. Dus is een fixme
tag misschien niet volledig noodzakelijk

De straatnaam id is in de posities database de enige manier om de
straatnaam te vinden. Dus als er enige overeenkomst tussen de databases is,
dan is het normaal dat je geen straatnaam-id vindt met twee verschillende
namen. De andere kant kan wel voor komen: dezelfde straatnaam (of bijna
dezelfde) met een verschillende straat id.


> Ik ben nu nog wat aan het kijken welke fouten ik met het python-script
> moet opsporen en welke best in de javascript naar boven gehaald kunnen
> worden in combinatie met de overpass-query. Het belangrijkste zijn de
> punten die samenvallen. Dat is een situatie die niet ingevoerd mag worden
> in OSM, dus ook hier lijkt een FIXME-tag mij het meest geschikt. Dat ga ik
> in elk geval nog even netjes documenteren.
>
> Ik zou het foutopsporen vooral voor de JS kant houden. Dan kunnen we dat
gemakkelijker aanpassen (zonder een script van een uur te draaien om dan
een klein tikfoutje te ontdekken).


> Nog een praktisch punt: hoe willen we deze tweede variant beschikbaar
> stellen? Moet dat naast de huidige komen te staan zodat we kunnen
> vergelijken, of moeten we juist vermijden dat er twee varianten in gebruik
> zijn en dat er verwarring ontstaat? Voor de gewone gebruiker is er
> eigenlijk geen verschil tussen beide systemen, dus dat is potentieel
> verwarrend. Anderzijds is het in de huidige beperkte opzet niet zo'n punt
> en misschien juist handig. Wat zijn jullie ideeën hierover?
>
> Ik zou het nog even naast elkaar houden, kwestie van vergelijking. Na het
evalueren van de tools kunnen die dan onder een beter adres beschikbaar
gesteld worden.

Host je het onder je eigen server (desnoods je eigen github account) of wil
je toegang tot de repo die ik nu heb?

Groeten,
Sander

>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] import AGIV CRAB-data

[Thomas]

Inmiddels ook de codering in gehoorzaamheid gedwongen. Blijkt dat de 
codering van de shapefile gewoon Latin-1 is en niet die vage CP-720. Dat 
scheelt ook maar weer.


De snelheid van mijn script valt me al bij al wel mee. Op dit moment 
gebruikt hij maar 1 thread. Het inlezen van het bestand in de 
dictionaries duurt zo'n 50 minuten. Het schrijven naar de JSON-bestanden 
een kleine 10 minuten (op een SSD'tje). Het schrijven gaat volgens mij 
wat trager omdat ik de adres-dictionary vervangen heb door een tuple. 
Dat scheelt toch een kleine 500MB in geheugengebruik. In totaal gebruikt 
het script maar iets van 2GB ram dacht ik, maar dat moet ik nog even 
nakijken. Sinds die wijziging heb ik in elk geval geen geheugenproblemen 
meer gehad.


Qua tags hoeven we inderdaad enkel de addr:housenumber en addr:street 
over te nemen. Daarnaast wil ik graag het herkomst-veld als tag 
invoeren, zodat de punten gestyled kunnen worden op basis daarvan. Naar 
mijn idee is die herkomst zeer bepalend voor de “nauwkeurigheid” van de 
punten. Ik heb dat nu geïmplementeerd als een “CRAB:herkomst”-tag. De 
Engelse variant “CRAB:source” vond ik een beetje misleidend. Aan de 
andere kant gaat het natuurlijk wel over hoe ze de locatie van het punt 
bepaald hebben. Dat kun je dus wel als “source” zien.


Daarnaast misschien nog iets van een tag om waarschuwingen mee te 
communiceren, bijvoorbeeld over de schrijfwijze van de straatnaam. Aan 
de andere kant heb ik geen enkel geval kunnen vinden waar twee adressen 
een zelfde straatnaam-id hebben maar een verschillende straatnaam 
(bijvoorbeeld een andere spelling). Dat soort fouten lijken me maar 
beperkt aanwezig en kunnen dus waarschijnlijk allemaal opgevangen worden 
met de FIXME-tag. Het huidige gebruik (om punten zonder locatie mee aan 
te geven) is in feite overbodig, omdat alle punten een locatie hebben.


Ik ben nu nog wat aan het kijken welke fouten ik met het python-script 
moet opsporen en welke best in de javascript naar boven gehaald kunnen 
worden in combinatie met de overpass-query. Het belangrijkste zijn de 
punten die samenvallen. Dat is een situatie die niet ingevoerd mag 
worden in OSM, dus ook hier lijkt een FIXME-tag mij het meest geschikt. 
Dat ga ik in elk geval nog even netjes documenteren.


Nog een praktisch punt: hoe willen we deze tweede variant beschikbaar 
stellen? Moet dat naast de huidige komen te staan zodat we kunnen 
vergelijken, of moeten we juist vermijden dat er twee varianten in 
gebruik zijn en dat er verwarring ontstaat? Voor de gewone gebruiker is 
er eigenlijk geen verschil tussen beide systemen, dus dat is potentieel 
verwarrend. Anderzijds is het in de huidige beperkte opzet niet zo'n 
punt en misschien juist handig. Wat zijn jullie ideeën hierover?


Groeten,
Thomas

Sander Deryckere schreef op 25-10-2014 20:17:



Op 25 oktober 2014 18:46 schreef Thomas >:


Ik ben inmiddels bijna klaar met het nieuwe script dat de
adressenlijst (in plaats van de adresposities) moet beschikbaar
stellen via de website die Sander gemaakt heeft.

Geweldig nieuws ;)

Het oude script kon ik maar voor kleine stukjes hergebruiken omdat
het bestandsformaat en de datastructuur toch redelijk anders zijn.
Ik ben uitgegaan van precies dezelfde JSON-uitwisselbestanden te
genereren zodat de website wel volledig compatibel is (op
misschien wat extra tags in javascript na dan). Het was niet
eenvoudig om een goed werkend script op te zetten vanwege de door
Sander genoemde coderingsproblemen en vanwege het feit dat deze
adressenlijst in feite 1 grote tabel is tegenover de adresposities
die in feite een 'database' zijn of een collectie van kleinere
tabellen. Daardoor liep ik tegen nogal wat geheugenprobleempjes aan.

De beschikbare modules om GML in te lezen in python bleken niet
robuust genoeg om én met de vreemde codering om te gaan én met de
enorme omvang van het bestand (ca. 3GB). Daarom heb ik ervoor
gekozen om als bron het shp-bestand te gebruiken (dat 'slechts'
1GB in omvang is, door een efficiëntere datastructuur). Daarmee
kreeg ik wel alles aan de praat.


Ik had ook al wat zaken opgezocht om het GML bestand te splitsen en 
pas daarna te verwerken, om zo slechts XML kind per kind in het 
geheugen te laden en geen geheugen tekort te komen. Maar dat werd een 
serieus gepruts, en ik verwachtte ook dat het te traag zou zijn door 
de vele lees en schrijf operaties.


Geheugenproblemen had ik sowieso verwacht, want zelft met het huidige 
script moet ik zorgen dat Firefox en JOSM alletwee gesloten zijn voor 
ik het script start. Anders loopt mijn computer onherroepelijk vast in 
het page-swapping.



Ik ben nu een aantal extra checks in de code aan het inbouwen en
te kijken wat handig is qua extra tags (evt. gekoppeld aan wat
CSS). Het blijft ook wat worstelen met de omvang. Mijn eerste
tests werken in elk geval bij mij. Als het een beetje wil komt dat
  

[OSM-talk-be] Validatie foutmelding: Onbenoemde wegen maar verbindings- voetpad heeft geen naam

[Jakka]

Dag,

Welke "name" tag dient om een naamloos pad of veldweg of verbindings- 
weg te geven zodanig dat de validatie geen foutmelding vertoont.

De noname=yes helpt niet

http://wiki.openstreetmap.org/wiki/Names#No_name

Hier kom ik niet uit (vermoedelijk voorstel?)
http://wiki.openstreetmap.org/wiki/Proposed_features/Noname#T:absent_.3D_yes

Jakka


___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] import AGIV CRAB-data

[Sander Deryckere]

Op 25 oktober 2014 18:46 schreef Thomas :

>  Ik ben inmiddels bijna klaar met het nieuwe script dat de adressenlijst
> (in plaats van de adresposities) moet beschikbaar stellen via de website
> die Sander gemaakt heeft.
>
> Geweldig nieuws ;)


> Het oude script kon ik maar voor kleine stukjes hergebruiken omdat het
> bestandsformaat en de datastructuur toch redelijk anders zijn. Ik ben
> uitgegaan van precies dezelfde JSON-uitwisselbestanden te genereren zodat
> de website wel volledig compatibel is (op misschien wat extra tags in
> javascript na dan). Het was niet eenvoudig om een goed werkend script op te
> zetten vanwege de door Sander genoemde coderingsproblemen en vanwege het
> feit dat deze adressenlijst in feite 1 grote tabel is tegenover de
> adresposities die in feite een 'database' zijn of een collectie van
> kleinere tabellen. Daardoor liep ik tegen nogal wat geheugenprobleempjes
> aan.
>


> De beschikbare modules om GML in te lezen in python bleken niet robuust
> genoeg om én met de vreemde codering om te gaan én met de enorme omvang van
> het bestand (ca. 3GB). Daarom heb ik ervoor gekozen om als bron het
> shp-bestand te gebruiken (dat 'slechts' 1GB in omvang is, door een
> efficiëntere datastructuur). Daarmee kreeg ik wel alles aan de praat.
>

Ik had ook al wat zaken opgezocht om het GML bestand te splitsen en pas
daarna te verwerken, om zo slechts XML kind per kind in het geheugen te
laden en geen geheugen tekort te komen. Maar dat werd een serieus gepruts,
en ik verwachtte ook dat het te traag zou zijn door de vele lees en schrijf
operaties.

Geheugenproblemen had ik sowieso verwacht, want zelft met het huidige
script moet ik zorgen dat Firefox en JOSM alletwee gesloten zijn voor ik
het script start. Anders loopt mijn computer onherroepelijk vast in het
page-swapping.

>
> Ik ben nu een aantal extra checks in de code aan het inbouwen en te kijken
> wat handig is qua extra tags (evt. gekoppeld aan wat CSS). Het blijft ook
> wat worstelen met de omvang. Mijn eerste tests werken in elk geval bij mij.
> Als het een beetje wil komt dat dus dit weekend af. Ook alle gemelde
> 'problemen' met de huidige dataset ga ik bekijken in deze nieuwe dataset.
>
> Voor alle duidelijkheid: voor de gebruikers verandert er weinig tot niets
> tegenover de huidige versie. Belangrijkste wijzigingen zijn het feit dat er
> punten zonder positie zullen zijn en dat er misschien wat extra tags
> automatisch ingeladen worden in JOSM als je een straat importeert. Die
> extra tags moeten helpen om de informatie naar waarde te schatten. In elk
> geval in deze eerste test-fase kunnen ze zeer handig zijn om beter bepaalde
> zaken te begrijpen.
>
> Ik heb nu voor het patroon “CRAB:key” gekozen als key voor de tags die ik
> in JOSM inlaad maar die niet in OSM thuishoren. Zijn er alternatieve
> patronen voor dit soort “tijdelijke” werk-tags die OSM nooit mogen
> bereiken? In de link die Marc eerder doorstuurde lees ik vooral dat onze
> Nederlanders een aantal overbodige tags in OSM hebben zitten n.a.v. een
> aantal imports. Het lijkt me op zich een mooi streven om al dat soort tags
> buiten OSM te houden, wat onze 'import' betreft.
>
> Moet er overigens nog een “source=CRAB”-tag toegevoegd worden, of willen
> we dit juist vermijden omdat het toch al niet om een automatische import
> gaat?
>

source=* tags zijn beter op hun plaats op het changeset object dan op
objecten in de DB. Natuurlijk kan een specifieke bron (zoals afkomstig van
de voordeur, gebouw or perceel) wel op het object zelf.

Postcode en gemeente zijn sowieso niet nodig, die kunnen gerust uit de JSON
gelaten worden. Welke andere keys twijfel je nog over?

>
> Groeten,
> Thomas
>
> Sander Deryckere schreef op 25-10-2014 17:52:
>
>Hmm, blijkbaar hebben alle tabellen een mogelijkheid tot deleten via
> "einddatum".
>
>  En blijkbaar gaat dat niet altijd samen.
>
>  Ik heb nu net eens het script laten lopen met alle records waar
> "einddatum" bijstond genegeerd, en dat resulteert vooral in terreinobjecten
> die genegeerd worden, waardoor er vooral extra adressen zonder positie zijn
> :/
>
>  Heb ook eens de Koningin Louisa-Marialaan bekeken met die nieuwe data, en
> daar blijkt er nu geen verschil te zijn O_o
>
>  Dus denk ik dat ik het script nog niet zal aanpassen.
>
>  Groeten,
>  Sander
>
> Op 25 oktober 2014 16:11 schreef Sander Deryckere :
>
>>
>>
>> Op 25 oktober 2014 14:48 schreef Sus Verhoeven :
>>
>>>  In Leopoldsburg 3970 op de Koningin-Louisalaan is er in CRAB een hele
>>> reeks huizen met dubbele huisnummers niet op dezelfde plaats, in GRB staat
>>> er maar een van deze reeksen.
>>>  Eigenaardig.
>>>
>>>  Sus
>>>
>>>
>>  Dit lijkt een straat die onlangs hernummerd is, en waarvan de oude
>> nummers nog niet verwijderd zijn.
>>
>>  Ook de GRB basiskaart is niet volledig duidelijk. Zo is er daar een
>> nummer 13-125 te zien, wat een veel te grote range is om te kunnen kloppen.
>> Ik zou voorstellen om eens ter plaatse te gaan kijken wat er nu echt jui

Re: [OSM-talk-be] import AGIV CRAB-data

[Jo]

Hallo Thomas,

Mooi werk (Sander ook natuurlijk!).

Eerst de vraagjes op het einde. De source hoort volgens mij thuis op de
changeset en niet op elk object apart.

JOSM gooit een aantal tags automatisch weg, voordat er geupload wordt.
created_by en odbl. De rest van de lijst zit in de verwijizing die Marc
aangaf.

Bij mijn importscripts voor TEC en De Lijn, voeg ik odbl=new/odbl=tt
toe (mbv MapCSS wordt dat dan een soort grafische todolist) en zet ik
overbodige adresgegevens in created_by. Deze zijn dan wel overbodig voor de
bushaltes, maar soms is het interessant om te weten bij welke straat zo'n
halte hoorde, of gewoon nog maar om te zien dat een straatnaam in OSM
waarschijnlijk fout is. (Dat was voordat we de beschikking hadden over AGIV
en CRAB).

Wat de (foute) huisnummers betreft die wel in OSM, maar niet in CRAB
zitten. Volgens mij zou het beter zijn om die volledig op te bouwen met dat
soort discardable tags, ipv addr:housenumber. Dat resulteert dan in tagloze
nodes die door de validatie in JOSM worden gerapporteerd in het geval
iemand op upload zou drukken, voordat deze manueel werden verwijderd. Of ze
stomweg zou vergeten, zoals mij nog wel zou kunnen overkomen...

Ik kan de MapCSS aanpassen zodat die er nog prominenter uitspringen dan de
rest.

Als die MapCSS 'klaar' is, dan zal ik ervoor zorgen dat die gemakkelijk
beschikbaar wordt in JOSM.

Wat de conversie betreft. Ik zou geneigd zijn om dat zootje eerst helemaal
in PostGIS te laden.
Dan een Overpass query en die info in een aparte tabel. Het probleem is dan
echter dat je ergens een platform nodig hebt, om dat te draaien en te
serven + web frontend.

Het voordeel is dat achteraf queries schrijven dan een stuk gemakkelijker
wordt en dat je ook progress reports kan maken.

Als we daar ooit een platform voor hebben, zou het niet slecht zijn, als we
dat ook voor De Lijn en TEC konden gebruiken. Nu doe ik dat zowat dagelijks
op mijn portable, maar wat als ik wegval? In Frankrijk hebben ze servers,
in Nederland misschien ook. Eventueel wil ik het daar wel eens vragen.

Zelf iets opzetten en hosten zie ik, eerlijk gezegd, ook niet zitten.
Vandaar dat ik de oplossing van Sander wel elegant vind.

Jo





Op 25 oktober 2014 18:46 schreef Thomas :

>  Ik ben inmiddels bijna klaar met het nieuwe script dat de adressenlijst
> (in plaats van de adresposities) moet beschikbaar stellen via de website
> die Sander gemaakt heeft.
>
> Het oude script kon ik maar voor kleine stukjes hergebruiken omdat het
> bestandsformaat en de datastructuur toch redelijk anders zijn. Ik ben
> uitgegaan van precies dezelfde JSON-uitwisselbestanden te genereren zodat
> de website wel volledig compatibel is (op misschien wat extra tags in
> javascript na dan). Het was niet eenvoudig om een goed werkend script op te
> zetten vanwege de door Sander genoemde coderingsproblemen en vanwege het
> feit dat deze adressenlijst in feite 1 grote tabel is tegenover de
> adresposities die in feite een 'database' zijn of een collectie van
> kleinere tabellen. Daardoor liep ik tegen nogal wat geheugenprobleempjes
> aan.
>
> De beschikbare modules om GML in te lezen in python bleken niet robuust
> genoeg om én met de vreemde codering om te gaan én met de enorme omvang van
> het bestand (ca. 3GB). Daarom heb ik ervoor gekozen om als bron het
> shp-bestand te gebruiken (dat 'slechts' 1GB in omvang is, door een
> efficiëntere datastructuur). Daarmee kreeg ik wel alles aan de praat.
>
> Ik ben nu een aantal extra checks in de code aan het inbouwen en te kijken
> wat handig is qua extra tags (evt. gekoppeld aan wat CSS). Het blijft ook
> wat worstelen met de omvang. Mijn eerste tests werken in elk geval bij mij.
> Als het een beetje wil komt dat dus dit weekend af. Ook alle gemelde
> 'problemen' met de huidige dataset ga ik bekijken in deze nieuwe dataset.
>
> Voor alle duidelijkheid: voor de gebruikers verandert er weinig tot niets
> tegenover de huidige versie. Belangrijkste wijzigingen zijn het feit dat er
> punten zonder positie zullen zijn en dat er misschien wat extra tags
> automatisch ingeladen worden in JOSM als je een straat importeert. Die
> extra tags moeten helpen om de informatie naar waarde te schatten. In elk
> geval in deze eerste test-fase kunnen ze zeer handig zijn om beter bepaalde
> zaken te begrijpen.
>
> Ik heb nu voor het patroon “CRAB:key” gekozen als key voor de tags die ik
> in JOSM inlaad maar die niet in OSM thuishoren. Zijn er alternatieve
> patronen voor dit soort “tijdelijke” werk-tags die OSM nooit mogen
> bereiken? In de link die Marc eerder doorstuurde lees ik vooral dat onze
> Nederlanders een aantal overbodige tags in OSM hebben zitten n.a.v. een
> aantal imports. Het lijkt me op zich een mooi streven om al dat soort tags
> buiten OSM te houden, wat onze 'import' betreft.
>
> Moet er overigens nog een “source=CRAB”-tag toegevoegd worden, of willen
> we dit juist vermijden omdat het toch al niet om een automatische import
> gaat?
>
> Groeten,
> Thomas
>
> Sand

Re: [OSM-talk-be] import AGIV CRAB-data

[Thomas]

Ik ben inmiddels bijna klaar met het nieuwe script dat de adressenlijst 
(in plaats van de adresposities) moet beschikbaar stellen via de website 
die Sander gemaakt heeft.


Het oude script kon ik maar voor kleine stukjes hergebruiken omdat het 
bestandsformaat en de datastructuur toch redelijk anders zijn. Ik ben 
uitgegaan van precies dezelfde JSON-uitwisselbestanden te genereren 
zodat de website wel volledig compatibel is (op misschien wat extra tags 
in javascript na dan). Het was niet eenvoudig om een goed werkend script 
op te zetten vanwege de door Sander genoemde coderingsproblemen en 
vanwege het feit dat deze adressenlijst in feite 1 grote tabel is 
tegenover de adresposities die in feite een 'database' zijn of een 
collectie van kleinere tabellen. Daardoor liep ik tegen nogal wat 
geheugenprobleempjes aan.


De beschikbare modules om GML in te lezen in python bleken niet robuust 
genoeg om én met de vreemde codering om te gaan én met de enorme omvang 
van het bestand (ca. 3GB). Daarom heb ik ervoor gekozen om als bron het 
shp-bestand te gebruiken (dat 'slechts' 1GB in omvang is, door een 
efficiëntere datastructuur). Daarmee kreeg ik wel alles aan de praat.


Ik ben nu een aantal extra checks in de code aan het inbouwen en te 
kijken wat handig is qua extra tags (evt. gekoppeld aan wat CSS). Het 
blijft ook wat worstelen met de omvang. Mijn eerste tests werken in elk 
geval bij mij. Als het een beetje wil komt dat dus dit weekend af. Ook 
alle gemelde 'problemen' met de huidige dataset ga ik bekijken in deze 
nieuwe dataset.


Voor alle duidelijkheid: voor de gebruikers verandert er weinig tot 
niets tegenover de huidige versie. Belangrijkste wijzigingen zijn het 
feit dat er punten zonder positie zullen zijn en dat er misschien wat 
extra tags automatisch ingeladen worden in JOSM als je een straat 
importeert. Die extra tags moeten helpen om de informatie naar waarde te 
schatten. In elk geval in deze eerste test-fase kunnen ze zeer handig 
zijn om beter bepaalde zaken te begrijpen.


Ik heb nu voor het patroon “CRAB:key” gekozen als key voor de tags die 
ik in JOSM inlaad maar die niet in OSM thuishoren. Zijn er alternatieve 
patronen voor dit soort “tijdelijke” werk-tags die OSM nooit mogen 
bereiken? In de link die Marc eerder doorstuurde lees ik vooral dat onze 
Nederlanders een aantal overbodige tags in OSM hebben zitten n.a.v. een 
aantal imports. Het lijkt me op zich een mooi streven om al dat soort 
tags buiten OSM te houden, wat onze 'import' betreft.


Moet er overigens nog een “source=CRAB”-tag toegevoegd worden, of willen 
we dit juist vermijden omdat het toch al niet om een automatische import 
gaat?


Groeten,
Thomas

Sander Deryckere schreef op 25-10-2014 17:52:
Hmm, blijkbaar hebben alle tabellen een mogelijkheid tot deleten via 
"einddatum".


En blijkbaar gaat dat niet altijd samen.

Ik heb nu net eens het script laten lopen met alle records waar 
"einddatum" bijstond genegeerd, en dat resulteert vooral in 
terreinobjecten die genegeerd worden, waardoor er vooral extra 
adressen zonder positie zijn :/


Heb ook eens de Koningin Louisa-Marialaan bekeken met die nieuwe data, 
en daar blijkt er nu geen verschil te zijn O_o


Dus denk ik dat ik het script nog niet zal aanpassen.

Groeten,
Sander

Op 25 oktober 2014 16:11 schreef Sander Deryckere >:




Op 25 oktober 2014 14:48 schreef Sus Verhoeven mailto:sus...@gmail.com>>:

In Leopoldsburg 3970 op de Koningin-Louisalaan is er in CRAB
een hele reeks huizen met dubbele huisnummers niet op dezelfde
plaats, in GRB staat er maar een van deze reeksen.
Eigenaardig.

Sus


Dit lijkt een straat die onlangs hernummerd is, en waarvan de oude
nummers nog niet verwijderd zijn.

Ook de GRB basiskaart is niet volledig duidelijk. Zo is er daar
een nummer 13-125 te zien, wat een veel te grote range is om te
kunnen kloppen. Ik zou voorstellen om eens ter plaatse te gaan
kijken wat er nu echt juist is.

Volgens de documentatie van de databases zouden ze verouderde
nummers moeten deleten door er een "einddatum" aan te geven. In
het extract script test ik ook op die einddatum, dus als ze
correct verwijderd zijn, dan zouden ze niet meer in de data mogen
voorkomen.

Het is natuurlijk niet eenvoudig om in dit geval te controleren
als het script of de data fout is, omdat het nu eenmaal niet vaak
gebeurt dat een straat hernummerd wordt.

In Leuven werd onlangs een straat hernummerd (zie
http://www.nieuwsblad.be/article/detail.aspx?articleid=DMF20130218_00473793)
en ik denk dat de CRAB data overeenkomt met de huidige data, dus
dat de verwijderde nummers wel degelijk niet meer zichtbaar zijn.
Maar 1 voorbeeld is natuurlijk wat weinig om op voort te gaan.

Groeten,
Sander




___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/

Re: [OSM-talk-be] import AGIV CRAB-data

[Jo]

Dan lijkt het mij aangewezen om op die plek een Note achter te laten. Ik
heb dat al hier en daar gedaan en al duurt het soms een paar maanden,
uiteindelijk worden die wel gezien en opgelost.

Jo

Op 25 oktober 2014 18:37 schreef Verhoeven Fr :

> Le 25/10/14 16:11, Sander Deryckere a écrit :
>
>>
>>
>> Dit lijkt een straat die onlangs hernummerd is, en waarvan de oude
>> nummers nog niet verwijderd zijn.
>>
> Ik vrrag mij zelfs af of men de naam niet verandert heeft.
> In Balen heeft men ook al hernummerd, maar daar stonden in AGIV 2 nummers.
>
>>
>> Ook de GRB basiskaart is niet volledig duidelijk. Zo is er daar een
>> nummer 13-125 te zien, wat een veel te grote range is om te kunnen kloppen.
>> Ik zou voorstellen om eens ter plaatse te gaan kijken wat er nu echt juist
>> is.
>>
>>  Ja maar, ik heb geen hond om mee gaan te wandelen :-P
> En het ligt ook niet bij huis.
>
> Groetjes
>
> Sus
>
>
>
> ___
> 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

Re: [OSM-talk-be] import AGIV CRAB-data

[Verhoeven Fr]

Le 25/10/14 16:11, Sander Deryckere a écrit :



Dit lijkt een straat die onlangs hernummerd is, en waarvan de oude 
nummers nog niet verwijderd zijn.

Ik vrrag mij zelfs af of men de naam niet verandert heeft.
In Balen heeft men ook al hernummerd, maar daar stonden in AGIV 2 nummers.


Ook de GRB basiskaart is niet volledig duidelijk. Zo is er daar een 
nummer 13-125 te zien, wat een veel te grote range is om te kunnen 
kloppen. Ik zou voorstellen om eens ter plaatse te gaan kijken wat er 
nu echt juist is.



Ja maar, ik heb geen hond om mee gaan te wandelen :-P
En het ligt ook niet bij huis.

Groetjes

Sus


___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] import AGIV CRAB-data

[Sander Deryckere]

Hmm, blijkbaar hebben alle tabellen een mogelijkheid tot deleten via
"einddatum".

En blijkbaar gaat dat niet altijd samen.

Ik heb nu net eens het script laten lopen met alle records waar "einddatum"
bijstond genegeerd, en dat resulteert vooral in terreinobjecten die
genegeerd worden, waardoor er vooral extra adressen zonder positie zijn :/

Heb ook eens de Koningin Louisa-Marialaan bekeken met die nieuwe data, en
daar blijkt er nu geen verschil te zijn O_o

Dus denk ik dat ik het script nog niet zal aanpassen.

Groeten,
Sander

Op 25 oktober 2014 16:11 schreef Sander Deryckere :

>
>
> Op 25 oktober 2014 14:48 schreef Sus Verhoeven :
>
>> In Leopoldsburg 3970 op de Koningin-Louisalaan is er in CRAB een hele
>> reeks huizen met dubbele huisnummers niet op dezelfde plaats, in GRB staat
>> er maar een van deze reeksen.
>> Eigenaardig.
>>
>> Sus
>>
>>
> Dit lijkt een straat die onlangs hernummerd is, en waarvan de oude nummers
> nog niet verwijderd zijn.
>
> Ook de GRB basiskaart is niet volledig duidelijk. Zo is er daar een nummer
> 13-125 te zien, wat een veel te grote range is om te kunnen kloppen. Ik zou
> voorstellen om eens ter plaatse te gaan kijken wat er nu echt juist is.
>
> Volgens de documentatie van de databases zouden ze verouderde nummers
> moeten deleten door er een "einddatum" aan te geven. In het extract script
> test ik ook op die einddatum, dus als ze correct verwijderd zijn, dan
> zouden ze niet meer in de data mogen voorkomen.
>
> Het is natuurlijk niet eenvoudig om in dit geval te controleren als het
> script of de data fout is, omdat het nu eenmaal niet vaak gebeurt dat een
> straat hernummerd wordt.
>
> In Leuven werd onlangs een straat hernummerd (zie
> http://www.nieuwsblad.be/article/detail.aspx?articleid=DMF20130218_00473793)
> en ik denk dat de CRAB data overeenkomt met de huidige data, dus dat de
> verwijderde nummers wel degelijk niet meer zichtbaar zijn. Maar 1 voorbeeld
> is natuurlijk wat weinig om op voort te gaan.
>
> Groeten,
> Sander
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Weekly OSM

[Marc Ducobu]

I started the redaction of the french version. Beware in the NL
version, the content of the "OpenStreetMap-Foundation" paragraph is
the content of the "Humanitarian OpenStreetMap Team"

.

On 24 October 2014 08:21, Marc Gemis  wrote:
> Thanks, nice to read it in Dutch. especially the Belgian touch you added :-)
>
> regards
>
> m
>
> On Thu, Oct 23, 2014 at 10:57 PM, Ben Abelshausen
>  wrote:
>>
>> Hi,
>>
>> I would like to announce a new thing I am trying to do that is very simple
>> but should introduce some continuity in our communication. I have posted the
>> first translation of the Weekly OSM blog in dutch on osm.be:
>>
>> http://osm.be/nl/content/weekly-osm-news-221
>>
>> Someone can translate into french if they want to. I can give you access
>> to the website. Will post this tomorrow on the twitter account and the
>> facebook group too.
>>
>> If you have osm-related news I should add please let me know. I will as
>> always follow the mailinglist and sometime extract things I find newsworthy
>> but feel free to nominate things you feel inportant and tell me.
>>
>> Met vriendelijke groeten,
>> Best regards,
>>
>> Ben Abelshausen
>>
>> ___
>> 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
>



-- 
et en avant pour de folles aventures...

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] LEZ

[Ben Laenen]

On Saturday 25 October 2014 17:12:01 Marc Gemis wrote:
> Er is onlangs even wat discussie geweest over dit topic op de Engelse
> mailing list. De vraag was of ze met punten of gebieden moesten werken.
> Gebieden is het enige correcte, maar dat kan je niet ter plaatse
> controleren. De enige source die ze hadden hield dan weer geen rekening met
> gebieden met een inrit buiten de LEZ.
> 
> Vandaar dat ze nog niet ver staan. Ze verwezen ook naar de Duitsers :-)

Lijkt me zo'n beetje dezelfde discussie als hoe je een bebouwde kom mapt...

Ben


___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] LEZ

[Marc Gemis]

Er is onlangs even wat discussie geweest over dit topic op de Engelse
mailing list. De vraag was of ze met punten of gebieden moesten werken.
Gebieden is het enige correcte, maar dat kan je niet ter plaatse
controleren. De enige source die ze hadden hield dan weer geen rekening met
gebieden met een inrit buiten de LEZ.

Vandaar dat ze nog niet ver staan. Ze verwezen ook naar de Duitsers :-)

mvg

m

2014-10-25 14:10 GMT+02:00 Gilbert Hersschens :

> Terwijl ik naar iets helemaal anders op zoek was kwam ik toevallig op de
> aankondiging van nieuwe verkeersborden terecht :
> http://www.wegcode.be/actueel/2091-wegcode-laat-toe-om-lage-emissiezones-te-beborden.
> UIteraard werd ik nieuwsgierig. Wat ik op een drafje bijeengesprokkeld heb
> is:
> - de borden vanaf nu reeds mogen geplaatst worden
> - de overheid nog geen normen gepubliceerd heeft wat "low emission"
> concreet inhoudt (dit zou België niet zijn...)
> - de stad Antwerpen LEZ wil invoeren vanaf Januari 2016
> - in OSM er geen duidelijke afpraken zijn hoe LEZ moet getagd worden. De
> Britten gebruiken een relatie van het type "LEZ", de Duitsers een relatie
> van het type "boundary" met als sub-tag boundary=low_emission_zone of een
> boundary zonder meer.
> In UK zie ik enkel de relatie 3937563 die zeer onvolledig is (
> http://ra.osmsurround.org/analyzeMap?relationId=3937563). Misschien is
> het maar een embryo ...
> De Duitsers hebben hun zaakjes blijkbaar wel al in orde.
> We hebben nog even de tijd om zelf een ei te leggen wat we hiermee gaan
> doen, maar ik zet het toch maar even op de agenda.
> Interessante links:
> http://wiki.openstreetmap.org/wiki/Umweltzone (enkel in het Duits)
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/boundary%3Dlow_emission_zone
> (talk page ook enkel in het Duits)
> http://wiki.openstreetmap.org/wiki/Low_emission_zone
>
> http://gis.stackexchange.com/questions/79715/how-to-find-out-if-openstreetmaps-contains-low-emission-zones
> http://taginfo.openstreetmap.org/tags/type=LEZ
> http://taginfo.openstreetmap.org/tags/boundary=low_emission_zone
> http://www.wegcode.be/pdf/wijzigingen/KB011275/2014-10-15.pdf
>
>
> ___
> 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

Re: [OSM-talk-be] import AGIV CRAB-data

[Sander Deryckere]

Op 25 oktober 2014 14:48 schreef Sus Verhoeven :

> In Leopoldsburg 3970 op de Koningin-Louisalaan is er in CRAB een hele
> reeks huizen met dubbele huisnummers niet op dezelfde plaats, in GRB staat
> er maar een van deze reeksen.
> Eigenaardig.
>
> Sus
>
>
Dit lijkt een straat die onlangs hernummerd is, en waarvan de oude nummers
nog niet verwijderd zijn.

Ook de GRB basiskaart is niet volledig duidelijk. Zo is er daar een nummer
13-125 te zien, wat een veel te grote range is om te kunnen kloppen. Ik zou
voorstellen om eens ter plaatse te gaan kijken wat er nu echt juist is.

Volgens de documentatie van de databases zouden ze verouderde nummers
moeten deleten door er een "einddatum" aan te geven. In het extract script
test ik ook op die einddatum, dus als ze correct verwijderd zijn, dan
zouden ze niet meer in de data mogen voorkomen.

Het is natuurlijk niet eenvoudig om in dit geval te controleren als het
script of de data fout is, omdat het nu eenmaal niet vaak gebeurt dat een
straat hernummerd wordt.

In Leuven werd onlangs een straat hernummerd (zie
http://www.nieuwsblad.be/article/detail.aspx?articleid=DMF20130218_00473793)
en ik denk dat de CRAB data overeenkomt met de huidige data, dus dat de
verwijderde nummers wel degelijk niet meer zichtbaar zijn. Maar 1 voorbeeld
is natuurlijk wat weinig om op voort te gaan.

Groeten,
Sander
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] import AGIV CRAB-data

[Sus Verhoeven]

In Leopoldsburg 3970 op de Koningin-Louisalaan is er in CRAB een hele reeks
huizen met dubbele huisnummers niet op dezelfde plaats, in GRB staat er
maar een van deze reeksen.
Eigenaardig.

Sus
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-be] LEZ

[Gilbert Hersschens]

Terwijl ik naar iets helemaal anders op zoek was kwam ik toevallig op de
aankondiging van nieuwe verkeersborden terecht :
http://www.wegcode.be/actueel/2091-wegcode-laat-toe-om-lage-emissiezones-te-beborden.
UIteraard werd ik nieuwsgierig. Wat ik op een drafje bijeengesprokkeld heb
is:
- de borden vanaf nu reeds mogen geplaatst worden
- de overheid nog geen normen gepubliceerd heeft wat "low emission"
concreet inhoudt (dit zou België niet zijn...)
- de stad Antwerpen LEZ wil invoeren vanaf Januari 2016
- in OSM er geen duidelijke afpraken zijn hoe LEZ moet getagd worden. De
Britten gebruiken een relatie van het type "LEZ", de Duitsers een relatie
van het type "boundary" met als sub-tag boundary=low_emission_zone of een
boundary zonder meer.
In UK zie ik enkel de relatie 3937563 die zeer onvolledig is (
http://ra.osmsurround.org/analyzeMap?relationId=3937563). Misschien is het
maar een embryo ...
De Duitsers hebben hun zaakjes blijkbaar wel al in orde.
We hebben nog even de tijd om zelf een ei te leggen wat we hiermee gaan
doen, maar ik zet het toch maar even op de agenda.
Interessante links:
http://wiki.openstreetmap.org/wiki/Umweltzone (enkel in het Duits)
http://wiki.openstreetmap.org/wiki/Proposed_features/boundary%3Dlow_emission_zone
(talk page ook enkel in het Duits)
http://wiki.openstreetmap.org/wiki/Low_emission_zone
http://gis.stackexchange.com/questions/79715/how-to-find-out-if-openstreetmaps-contains-low-emission-zones
http://taginfo.openstreetmap.org/tags/type=LEZ
http://taginfo.openstreetmap.org/tags/boundary=low_emission_zone
http://www.wegcode.be/pdf/wijzigingen/KB011275/2014-10-15.pdf
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] import AGIV CRAB-data

[Sander Deryckere]

Als ik op info -> meer info klik, dan kom ik op deze pagina:
http://www.geopunt.be/catalogus/datasetfolder/6EF348E1-69EB-4CAD-8CCD-1C68099AFCF3

Dewelke doet vermoeden dat het om de adressenlijst gaat, terwijl wij nog de
adressenposities gebruiken (met het plan om naar de adressenlijst over te
schakelen indien tijd en goesting).

Het is dus perfect mogelijk dat de nummers (en zeker de posities van de
nummers) verschillen tussen de twee tools.

De GRB basiskaart is dan volgens mij weer afgeleid van xGrab, dewelke nog
eens verschilt van de twee bovenstaande.

Groeten,
Sander


Op 25 oktober 2014 12:57 schreef Gilbert Hersschens :

> De lijst die ik met Aardseweg krijg lijkt nu idd correct. Geen idee waarom
> ik daarnet een ander resultaat kreeg.
> De huisnrs op de kaart van geopunt.be zijn "adrespunten". Ik veronderstel
> dat dit de adresposities zijn ?
>
> 2014-10-25 12:13 GMT+02:00 Sander Deryckere :
>
>>
>>
>> Op 25 oktober 2014 11:38 schreef Gilbert Hersschens <
>> gherssch...@gmail.com>:
>>
>>> De vormen van de gevellijnen op GRB zijn heel onbetrouwbaar. Misschien
>>> gebaseerd op de oorspronkelijke bouwplannen? Ik gebruik de AGIV luchtfoto's
>>> en ga soms nog eens bij Bing kijken als ik er niet goed aan uit kan.
>>> Op geopunt.be kan je de adrespunten als afzonderlijke laag inladen.
>>> Volgen de GIS ambtenaar in Geel komen die rechtstreeks uit CRAB. Die geven
>>> de juiste nummers (15, 17) weer. Misschien gebruik jij niet de juiste adres
>>> velden van de DB ?
>>>
>>
>> Welke CRAB database? Adressen_positities, Adressen_lijst of xGrab?
>>
>> Het is natuurlijk altijd mogelijk dat ik een verkeerd veld genomen heb
>> die in 99% van de gevallen toevallig overeenkomt met het huisnummer, en in
>> de andere gevallen een niet-gerelateerd nummer geeft.
>>
>>
>>> Ik krijg ook nog andere rare fouten. Als ik de Aardseweg injlaad, dan
>>> geeft hij nagenoeg alle adressen als missing op terwijl die huizen wel
>>> degelijk (bijna) allemaal genummerd zijn ?
>>>
>>> Ik krijg 6 missing met positie en 3 zonder positie:
>> http://sanderd17.github.io/import.html?pcode=2440&filterStreets=Aard*&maxDistance=&loadOsm=true
>>
>>
>>
>> ___
>> 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

Re: [OSM-talk-be] import AGIV CRAB-data

[Gilbert Hersschens]

De lijst die ik met Aardseweg krijg lijkt nu idd correct. Geen idee waarom
ik daarnet een ander resultaat kreeg.
De huisnrs op de kaart van geopunt.be zijn "adrespunten". Ik veronderstel
dat dit de adresposities zijn ?

2014-10-25 12:13 GMT+02:00 Sander Deryckere :

>
>
> Op 25 oktober 2014 11:38 schreef Gilbert Hersschens  >:
>
>> De vormen van de gevellijnen op GRB zijn heel onbetrouwbaar. Misschien
>> gebaseerd op de oorspronkelijke bouwplannen? Ik gebruik de AGIV luchtfoto's
>> en ga soms nog eens bij Bing kijken als ik er niet goed aan uit kan.
>> Op geopunt.be kan je de adrespunten als afzonderlijke laag inladen.
>> Volgen de GIS ambtenaar in Geel komen die rechtstreeks uit CRAB. Die geven
>> de juiste nummers (15, 17) weer. Misschien gebruik jij niet de juiste adres
>> velden van de DB ?
>>
>
> Welke CRAB database? Adressen_positities, Adressen_lijst of xGrab?
>
> Het is natuurlijk altijd mogelijk dat ik een verkeerd veld genomen heb die
> in 99% van de gevallen toevallig overeenkomt met het huisnummer, en in de
> andere gevallen een niet-gerelateerd nummer geeft.
>
>
>> Ik krijg ook nog andere rare fouten. Als ik de Aardseweg injlaad, dan
>> geeft hij nagenoeg alle adressen als missing op terwijl die huizen wel
>> degelijk (bijna) allemaal genummerd zijn ?
>>
>> Ik krijg 6 missing met positie en 3 zonder positie:
> http://sanderd17.github.io/import.html?pcode=2440&filterStreets=Aard*&maxDistance=&loadOsm=true
>
>
>
> ___
> 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

Re: [OSM-talk-be] import AGIV CRAB-data

[Sander Deryckere]

Op 25 oktober 2014 11:38 schreef Gilbert Hersschens :

> De vormen van de gevellijnen op GRB zijn heel onbetrouwbaar. Misschien
> gebaseerd op de oorspronkelijke bouwplannen? Ik gebruik de AGIV luchtfoto's
> en ga soms nog eens bij Bing kijken als ik er niet goed aan uit kan.
> Op geopunt.be kan je de adrespunten als afzonderlijke laag inladen.
> Volgen de GIS ambtenaar in Geel komen die rechtstreeks uit CRAB. Die geven
> de juiste nummers (15, 17) weer. Misschien gebruik jij niet de juiste adres
> velden van de DB ?
>

Welke CRAB database? Adressen_positities, Adressen_lijst of xGrab?

Het is natuurlijk altijd mogelijk dat ik een verkeerd veld genomen heb die
in 99% van de gevallen toevallig overeenkomt met het huisnummer, en in de
andere gevallen een niet-gerelateerd nummer geeft.


> Ik krijg ook nog andere rare fouten. Als ik de Aardseweg injlaad, dan
> geeft hij nagenoeg alle adressen als missing op terwijl die huizen wel
> degelijk (bijna) allemaal genummerd zijn ?
>
> Ik krijg 6 missing met positie en 3 zonder positie:
http://sanderd17.github.io/import.html?pcode=2440&filterStreets=Aard*&maxDistance=&loadOsm=true
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] import AGIV CRAB-data

[Gilbert Hersschens]

De vormen van de gevellijnen op GRB zijn heel onbetrouwbaar. Misschien
gebaseerd op de oorspronkelijke bouwplannen? Ik gebruik de AGIV luchtfoto's
en ga soms nog eens bij Bing kijken als ik er niet goed aan uit kan.
Op geopunt.be kan je de adrespunten als afzonderlijke laag inladen. Volgen
de GIS ambtenaar in Geel komen die rechtstreeks uit CRAB. Die geven de
juiste nummers (15, 17) weer. Misschien gebruik jij niet de juiste adres
velden van de DB ?
Ik krijg ook nog andere rare fouten. Als ik de Aardseweg injlaad, dan geeft
hij nagenoeg alle adressen als missing op terwijl die huizen wel degelijk
(bijna) allemaal genummerd zijn ?


2014-10-25 11:19 GMT+02:00 Sander Deryckere :

>
>
> Op 25 oktober 2014 10:55 schreef Gilbert Hersschens  >:
>
>> Ik heb het script even uitgeprobeerd en zie toch een paar rare dingen -
>> Misschien te wijten aan fouten in CRAB ?
>> Dit is het stukje van de kaart :
>> http://osm.org/go/0ErRh7ZyY?m=&way=70085786.
>> Als ik het script laat lopen voor postcode 2440, street = Mastbos, dan
>> krijg ik Total = 19, Missing = 3, Wrong = 2.
>> "Missing" (nr 26) zou nog juist kunnen zijn, daar het een nieuwe wijk is
>> en er intussen een huis kan bijgekomen zijn dat nog niet op de luchtfoto's
>> te zien is. Ik zal deze namiddag eens ter plekke gaan kijken. Op de kaart
>> van AGIV staat echter geen huis getekend, wel een huisnummer. Als ik in
>> JOSM met de wms voor GRB-raadpleegdiensten de huisnummers (GRB-HNR_GBG)
>> inlaad, dan is nr 26 er niet bij. Als ik de perceelsnummers (GRB-HNR_ADP)
>> inlaad dan is nr 26 er als enige in die straat.
>> Bij de foute nummers geeft jouw script de nrs 15 en 17 op die resp. (=
>> missing) 71 en 41 zouden moeten zijn, alhoewel die huizen op de kaart van
>> AGIV wel degelijk als 15 en 17 genummerd zijn ? Als je de locatie met de
>> AGIV GDI viewer opzoekt (ik gebruik meestal geopunt.be) en je daar naar
>> de lijst van huisnummers kijkt, dab komen de nrs 71 en 41 ook helemaal niet
>> voor op de lijst.
>>
>>
> Proficiat, je hebt net enkele nieuwe fouten ontdekt in die database ;)
> (let er trouwens op dat de vorm van die huizen op de GRB basiskaart wel
> zeer raar is).
>
> Die 26 zou ik niet als een fout zien. Soms krijgen bouwpercelen ook een
> huisnummer, en het is volgens mij niet fout om dat ook zo in OSM te zetten,
> elfs als er geen brievenbus is (misschien met een extra tag om het verschil
> te maken). In advertenties om die bouwgrond te verkopen kan dat onbebouwd
> perceel namelijk al aangeduid worden met dat huisnummer, en wanneer er wel
> een huis op komt, dan kunnen de eerste bewoners meteen vrienden ontvangen
> die de GPS gebruiken om het nieuwe huis te vinden ;)
>
> Maar die 71 en 41 zijn duidelijk fout. Ze komen ook rechtstreeks zo uit de
> adressen_posities database. Mogelijks staan die wel correct in hun
> adressen_lijst database. Het lijkt er meer en meer op dat die verschillende
> databases niet echt verbonden zijn, en dat ze elk afzonderlijk onderhouden
> worden.
>
> Als je wil, dan mag je dat melden aan AGIV, dan zullen ze het hopelijk
> aanpassen, en zal bij een volgende update het gecorrigeerd zijn.
>
> Het zou ook goed zijn om die fouten ergens te gaan documenteren, op de
> wiki bijvoorbeeld.
>
> Groeten,
> Sander
>
>
> ___
> 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

Re: [OSM-talk-be] import AGIV CRAB-data

[Sus Verhoeven]

Hooi,
Het is gefixt dank zij de script van Jo uw de goede uitleg.
Ik gebruik het enkel om de CRAP gegevens op het scherm te krijgen. Als het
te ingewikkeld wordt zet ik gewoon niets in OSM.
 Ze moeten maar bij de geburen gaan bellen. ;-)

Sus


2014-10-25 9:55 GMT+02:00 Sander Deryckere :

>
>
> Op 25 oktober 2014 09:21 schreef Verhoeven Fr :
>
>>  Hooi Sander,
>> Hopelijk blijft uw tool "as is" beschikbaar.
>>
>
> Momenteel wel, ik heb er geen kosten of onderhoud aan. Al het rekenwerk
> gebeurt door Overpass of door je eigen computer.
>
>
>> Ik gebruik het nu in Leopoldsburg om de reeds vroeger door mij
>> ingetekende huizen te nummeren samen met de GRB gegevens. Al de Crab data
>> ligt in Leopoldsburg op  de perceel-centroid,  dus soms ver van de
>> gebouwen, en de percelen zijn daar soms uitgestrekt.
>> Ik heb ook al vastgesteld dat de AGIV mappers ook hun eigen stijl hebben,
>> ( zoals bij OSM ;-)  ), en er volgens de regio verschillen zitten. In
>> Agiv ligt het huisnummer, in dezelfde straat, soms op de gebouwen, soms op
>> de percelen, zonder vaste regel. Ik leg ze i, OSM op de gebouwen.
>> Het enige opmerking is dat het huisnummer op de tagnode heel klein is en
>> soms moeilijk leesbaar, althans op een netbook
>>
>
> Dat kan opgelost worden met de mapCSS van Jo:
>
> node["addr:housenumber"]:new::
> housenumber
>  {text-color: blue;
>   font-size: 25;
>   text:  tag("addr:housenumber");
>   text-halo-radius: 2;
>   text-offset-y: 30;}
>
> Kopieer deze CSS code naar een tekst bestand, en noem het b.v.
> huisnummers.mapcss. Dan ga je in JOSM naar View -> Map pain styles -> Map
> paint preferences. Daar klik je rechts op het +-teken, geef je een naam in,
> en laad je het huisnummers.mapcss bestand.
>
> Als je nu de stijl aanvinkt onder View -> Map paint styles, dan zullen de
> huisnummers beter leesbaar zijn.
>
> Let wel op, die CSS is nog voorlopig, en zal misschien verbeterd worden in
> de toekomst (waar we dan verschillende types misschien verschillende
> kleuren kunnen geven).
>
>
>
>
> ___
> 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

Re: [OSM-talk-be] import AGIV CRAB-data

[Sander Deryckere]

Op 25 oktober 2014 10:55 schreef Gilbert Hersschens :

> Ik heb het script even uitgeprobeerd en zie toch een paar rare dingen -
> Misschien te wijten aan fouten in CRAB ?
> Dit is het stukje van de kaart :
> http://osm.org/go/0ErRh7ZyY?m=&way=70085786.
> Als ik het script laat lopen voor postcode 2440, street = Mastbos, dan
> krijg ik Total = 19, Missing = 3, Wrong = 2.
> "Missing" (nr 26) zou nog juist kunnen zijn, daar het een nieuwe wijk is
> en er intussen een huis kan bijgekomen zijn dat nog niet op de luchtfoto's
> te zien is. Ik zal deze namiddag eens ter plekke gaan kijken. Op de kaart
> van AGIV staat echter geen huis getekend, wel een huisnummer. Als ik in
> JOSM met de wms voor GRB-raadpleegdiensten de huisnummers (GRB-HNR_GBG)
> inlaad, dan is nr 26 er niet bij. Als ik de perceelsnummers (GRB-HNR_ADP)
> inlaad dan is nr 26 er als enige in die straat.
> Bij de foute nummers geeft jouw script de nrs 15 en 17 op die resp. (=
> missing) 71 en 41 zouden moeten zijn, alhoewel die huizen op de kaart van
> AGIV wel degelijk als 15 en 17 genummerd zijn ? Als je de locatie met de
> AGIV GDI viewer opzoekt (ik gebruik meestal geopunt.be) en je daar naar
> de lijst van huisnummers kijkt, dab komen de nrs 71 en 41 ook helemaal niet
> voor op de lijst.
>
>
Proficiat, je hebt net enkele nieuwe fouten ontdekt in die database ;) (let
er trouwens op dat de vorm van die huizen op de GRB basiskaart wel zeer
raar is).

Die 26 zou ik niet als een fout zien. Soms krijgen bouwpercelen ook een
huisnummer, en het is volgens mij niet fout om dat ook zo in OSM te zetten,
elfs als er geen brievenbus is (misschien met een extra tag om het verschil
te maken). In advertenties om die bouwgrond te verkopen kan dat onbebouwd
perceel namelijk al aangeduid worden met dat huisnummer, en wanneer er wel
een huis op komt, dan kunnen de eerste bewoners meteen vrienden ontvangen
die de GPS gebruiken om het nieuwe huis te vinden ;)

Maar die 71 en 41 zijn duidelijk fout. Ze komen ook rechtstreeks zo uit de
adressen_posities database. Mogelijks staan die wel correct in hun
adressen_lijst database. Het lijkt er meer en meer op dat die verschillende
databases niet echt verbonden zijn, en dat ze elk afzonderlijk onderhouden
worden.

Als je wil, dan mag je dat melden aan AGIV, dan zullen ze het hopelijk
aanpassen, en zal bij een volgende update het gecorrigeerd zijn.

Het zou ook goed zijn om die fouten ergens te gaan documenteren, op de wiki
bijvoorbeeld.

Groeten,
Sander
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] import AGIV CRAB-data

[Gilbert Hersschens]

Ik heb het script even uitgeprobeerd en zie toch een paar rare dingen -
Misschien te wijten aan fouten in CRAB ?
Dit is het stukje van de kaart : http://osm.org/go/0ErRh7ZyY?m=&way=70085786
.
Als ik het script laat lopen voor postcode 2440, street = Mastbos, dan
krijg ik Total = 19, Missing = 3, Wrong = 2.
"Missing" (nr 26) zou nog juist kunnen zijn, daar het een nieuwe wijk is en
er intussen een huis kan bijgekomen zijn dat nog niet op de luchtfoto's te
zien is. Ik zal deze namiddag eens ter plekke gaan kijken. Op de kaart van
AGIV staat echter geen huis getekend, wel een huisnummer. Als ik in JOSM
met de wms voor GRB-raadpleegdiensten de huisnummers (GRB-HNR_GBG) inlaad,
dan is nr 26 er niet bij. Als ik de perceelsnummers (GRB-HNR_ADP) inlaad
dan is nr 26 er als enige in die straat.
Bij de foute nummers geeft jouw script de nrs 15 en 17 op die resp. (=
missing) 71 en 41 zouden moeten zijn, alhoewel die huizen op de kaart van
AGIV wel degelijk als 15 en 17 genummerd zijn ? Als je de locatie met de
AGIV GDI viewer opzoekt (ik gebruik meestal geopunt.be) en je daar naar de
lijst van huisnummers kijkt, dab komen de nrs 71 en 41 ook helemaal niet
voor op de lijst.

2014-10-25 9:55 GMT+02:00 Sander Deryckere :

>
>
> Op 25 oktober 2014 09:21 schreef Verhoeven Fr :
>
>>  Hooi Sander,
>> Hopelijk blijft uw tool "as is" beschikbaar.
>>
>
> Momenteel wel, ik heb er geen kosten of onderhoud aan. Al het rekenwerk
> gebeurt door Overpass of door je eigen computer.
>
>
>> Ik gebruik het nu in Leopoldsburg om de reeds vroeger door mij
>> ingetekende huizen te nummeren samen met de GRB gegevens. Al de Crab data
>> ligt in Leopoldsburg op  de perceel-centroid,  dus soms ver van de
>> gebouwen, en de percelen zijn daar soms uitgestrekt.
>> Ik heb ook al vastgesteld dat de AGIV mappers ook hun eigen stijl hebben,
>> ( zoals bij OSM ;-)  ), en er volgens de regio verschillen zitten. In
>> Agiv ligt het huisnummer, in dezelfde straat, soms op de gebouwen, soms op
>> de percelen, zonder vaste regel. Ik leg ze i, OSM op de gebouwen.
>> Het enige opmerking is dat het huisnummer op de tagnode heel klein is en
>> soms moeilijk leesbaar, althans op een netbook
>>
>
> Dat kan opgelost worden met de mapCSS van Jo:
>
> node["addr:housenumber"]:new::
> housenumber
>  {text-color: blue;
>   font-size: 25;
>   text:  tag("addr:housenumber");
>   text-halo-radius: 2;
>   text-offset-y: 30;}
>
> Kopieer deze CSS code naar een tekst bestand, en noem het b.v.
> huisnummers.mapcss. Dan ga je in JOSM naar View -> Map pain styles -> Map
> paint preferences. Daar klik je rechts op het +-teken, geef je een naam in,
> en laad je het huisnummers.mapcss bestand.
>
> Als je nu de stijl aanvinkt onder View -> Map paint styles, dan zullen de
> huisnummers beter leesbaar zijn.
>
> Let wel op, die CSS is nog voorlopig, en zal misschien verbeterd worden in
> de toekomst (waar we dan verschillende types misschien verschillende
> kleuren kunnen geven).
>
>
>
>
> ___
> 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

Re: [OSM-talk-be] import AGIV CRAB-data

[Sander Deryckere]

Op 25 oktober 2014 09:21 schreef Verhoeven Fr :

>  Hooi Sander,
> Hopelijk blijft uw tool "as is" beschikbaar.
>

Momenteel wel, ik heb er geen kosten of onderhoud aan. Al het rekenwerk
gebeurt door Overpass of door je eigen computer.


> Ik gebruik het nu in Leopoldsburg om de reeds vroeger door mij ingetekende
> huizen te nummeren samen met de GRB gegevens. Al de Crab data ligt in
> Leopoldsburg op  de perceel-centroid,  dus soms ver van de gebouwen, en de
> percelen zijn daar soms uitgestrekt.
> Ik heb ook al vastgesteld dat de AGIV mappers ook hun eigen stijl hebben,
> ( zoals bij OSM ;-)  ), en er volgens de regio verschillen zitten. In
> Agiv ligt het huisnummer, in dezelfde straat, soms op de gebouwen, soms op
> de percelen, zonder vaste regel. Ik leg ze i, OSM op de gebouwen.
> Het enige opmerking is dat het huisnummer op de tagnode heel klein is en
> soms moeilijk leesbaar, althans op een netbook
>

Dat kan opgelost worden met de mapCSS van Jo:

node["addr:housenumber"]:new::
housenumber
 {text-color: blue;
  font-size: 25;
  text:  tag("addr:housenumber");
  text-halo-radius: 2;
  text-offset-y: 30;}

Kopieer deze CSS code naar een tekst bestand, en noem het b.v.
huisnummers.mapcss. Dan ga je in JOSM naar View -> Map pain styles -> Map
paint preferences. Daar klik je rechts op het +-teken, geef je een naam in,
en laad je het huisnummers.mapcss bestand.

Als je nu de stijl aanvinkt onder View -> Map paint styles, dan zullen de
huisnummers beter leesbaar zijn.

Let wel op, die CSS is nog voorlopig, en zal misschien verbeterd worden in
de toekomst (waar we dan verschillende types misschien verschillende
kleuren kunnen geven).
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] import AGIV CRAB-data

[Verhoeven Fr]

Hooi Sander,
Hopelijk blijft uw tool "as is" beschikbaar.
Ik gebruik het nu in Leopoldsburg om de reeds vroeger door mij 
ingetekende huizen te nummeren samen met de GRB gegevens. Al de Crab 
data ligt in Leopoldsburg op  de perceel-centroid,  dus soms ver van de 
gebouwen, en de percelen zijn daar soms uitgestrekt.
Ik heb ook al vastgesteld dat de AGIV mappers ook hun eigen stijl 
hebben, ( zoals bij OSM ;-) ), en er volgens de regio verschillen 
zitten. In Agiv ligt het huisnummer, in dezelfde straat, soms op de 
gebouwen, soms op de percelen, zonder vaste regel. Ik leg ze i, OSM op 
de gebouwen.
Het enige opmerking is dat het huisnummer op de tagnode heel klein is en 
soms moeilijk leesbaar, althans op een netbook.

Nogmaals bedankt.

Sus




Le 24/10/14 13:57, Sander Deryckere a écrit :

Bah,

Daar waar ik dacht dat we aan de eindspurt richting goeie tools bezig 
waren, staan we terug aan het begin. Na een maand programmeren.


Ik heb nu even geen zin meer om het script van CRAB naar JSON te 
herschrijven voor die andere database structuur.


Ik vind het goed genoeg zoals het is. Hebben we die enkele 
voordeurlocaties echt nodig? Enkel toegang tot de gebouwcontouren zou 
een echt nieuwe uitdaging geven (en met nut).


Maar als iemand zin heeft om er verder aan te werken, de code is vrij 
om te forken.


Mvg,
Sander




___
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