Jo,
De documentatie over de import is ongeveer gereed (enkel nog LARA
documenteren in de Engelse versie, en de beginpagina aanpassen). Zou jij de
MapCSS ergens willen publiceren?
Dan hoop ik binnenkort de discussie op de import lijst te herbeginnen.
Bedankt,
Sander
Op 8 november 2014 23:20
Dag Sander,
Met de script krijgt men soms opgestapelde huisnummers wanneer er in
AGIV GRB een huis is met 2 nummers of op de huizen die in een reeks
opgestapeld zijn.
BV. 3970, Sint Antoniusstraat, 9-21 en 7-23 (in GRB) in het begin van
de straat, ook de opgegeven nummers op de tag van de
@Glenn: Ik begrijp niet goed wat je wil zeggen. Door ze als
addr:official_housenumber te taggen gaan ze net extra bovenkomen (met
overpass kan je bijvoorbeeld eenvoudig zoeken waar die liggen).
Een goeie geocoder (die in tegenstelling tot Nominatim ook goed werkt met
Belgische adressen) zou het
Voor mij hoeft dat niet.
Ik ben voornamelijk een OSM gebruiker en ik vermoed dat dat in geen
enkele applicatie ga terugvinden. Wat mij interesseert is een huisnummer
in mijn smartfone in te geven en dat die voor mij de weg uitzoekt.
Ik heb mij altijd afgevraagd wat het nut was van al die
Je kan ook gewoon in je browser
mijnlijn.be/x0zxyz intypen, als je al aan de bushalte staat.
Ze hebben bij De Lijn nu ook hun mobiele site aangepast en het is nu een
stuk eenvoudiger om haltes op te zoeken. In OsmAnd kan je ook op de haltes
klikken, maar je kan niet doorklikken naar de realtime
Sander,
Ik denk dat die addr:official_housenumber op 1 node een betere oplossing is
dan al die nodes bovenop elkaar. In het begin was er ook een veld met
daarin 20-28. Was dat gegenereerd, of zit dat ook ergens zo in de CRAB-data?
Sus, we zitten nog maar in de testfase en dat probleem van
Op 8-nov.-2014 23:07 schreef Jo winfi...@gmail.com:
Sander,
Ik denk dat die addr:official_housenumber op 1 node een betere oplossing
is dan al die nodes bovenop elkaar. In het begin was er ook een veld met
daarin 20-28. Was dat gegenereerd, of zit dat ook ergens zo in de CRAB-data?
Als je de
Ik heb ontdekt dat het CRAB blijkbaar vaak huisnummers heeft die in het
echt niet zichtbaar zijn. Daaronder vallen de eerder genoemde percelen die
genummerd zijn (zonder gebouw), maar soms krijgt 1 huis ook meerdere
nummers, terwijl er van buiten maar 1 zichtbaar is (en er eigenlijk maar 1
Ik had altijd begrepen dat je een huisnummer ook aan een perceel kan
toewijzen. o.a. voor die braakliggende terreinen, maar bijv. ook voor
scholen met meerdere gebouwen of sites waar meerdere industriële gebouwen
hetzelfde adres hebben.
Dus voor die braakliggende terreinen, kan het huidige
Je kan voor de deur voor leveranciers de tag entrance=service gebruiken.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
Ondertussen heb ik contact gehad met Jan Laporte van AGIV, en hij heeft mij
één en ander verduidelijkt.
Vooraleerst, het verschil tussen bus- en appartementsnumers is dat er in
busnummers geen betekenis zit, terwijl er in appartementsnummers wel een
betekenis zit (bijvoorbeeld, nummer 203 kan
En natuurlijk is net nu Overpass terug online.
Het script gebruikt nu opnieuw de Duitse versie, dus moet alles terug
werken.
Op 4 november 2014 08:49 schreef Sander Deryckere sander...@gmail.com:
CRAB gebruikt idd enkel de gemeentenaam, en dat is ook de voorkeur van de
Post.
Dit is nog maar
Het kan geen kwaad dat het script nu wat robuuster is. Het geeft wel aan
hoe nuttig die Overpass API is, maar ook hoe afhankelijk we er van geworden
zijn.
Ik kan ook niet uit de voeten met de Franse of de Russische instances. Ik
zal 's moeten nakijken wat voor speciale zaken ik dan wel gebruik in
Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig
gehouden met de ontwikkeling van het javascript-gedeelte van de website.
Op dit moment kan ik de Russische output ook moeilijk vergelijken met de
Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog
steeds
Wel, ik gebruik de out center abstractie van overpass (het bespaart me de
moeite om zelf de centra te berekenen, en het bespaart bandbreedte), en die
feature is nog maar enkele maanden uit.
Dus misschien ontbreekt die nog op de Russische versie.
Groeten,
Sander
Op 3-nov.-2014 09:39 schreef
Misschien 's op de Franse server proberen:
http://oapi-fr.openstreetmap.fr/oapi
Jo
Op 3 november 2014 10:24 schreef Sander Deryckere sander...@gmail.com:
Wel, ik gebruik de out center abstractie van overpass (het bespaart me
de moeite om zelf de centra te berekenen, en het bespaart
Dit is het volledige adres:
http://oapi-fr.openstreetmap.fr/oapi/interpreter
Die geeft wel steeds een gezipt antwoord, blijkbaar. En mijn query voor
alles wat met openbaar vervoer te maken heeft in België kan hij niet aan.
jo
Op 3 november 2014 12:46 schreef Jo winfi...@gmail.com:
Misschien
Met gezipte antwoorden kan JS niet overweg.
Ik denk dat er niets anders op zit dan te wachten tot de Duitse versie weer
werkt, of de Russische versie hun software heeft geupdated.
De code wijzigen voor de (hopelijk) enkele dagen dat dit ongemak zal duren
heeft volgens mij geen zin.
Groeten,
Ik heb 's een straat in 3010 Kessel-Lo afgehaald. Vreemd genoeg komt daar
nu addr:city=Leuven uit. Zitten de deelgemeentes ook in de data van CRAB?
Ik vind 3010 of 3012 Leuven ipv Kessel-Lo/Wilsele niet bepaald logisch. Al
weet ik wel dat je dat wat De Post betreft ook zo mag schrijven. Als het zo
Die gemeentenaam komt uit de CRAB-data. Ik denk dat dat losstaat van de
Overpass Query.
Jo
Op 3 november 2014 23:59 schreef Glenn Plas gl...@byte-consult.be:
Ik zou het nu niet gebruiken, de Russische data komt niet goed. Als de
duitse overpass api terug goed werkt zal het beter gaan. Ik
3010 Leuven is de enige correcte schrijfwijze: Leuven is de gemeente,
niet Kessel-Lo.
http://www.bpost.be/adressering/#2
• Gebruik bij voorkeur de naam van de fusiegemeente (die van uw gemeentehuis).
2014-11-03 23:48 GMT+01:00 Jo winfi...@gmail.com:
Ik heb 's een straat in 3010 Kessel-Lo
Wat De Post betreft dus wel, ja. Weet jij waar 3018 Leuven is?
Jo
Op 4 november 2014 00:04 schreef Johan Van de Wauw
johan.vandew...@gmail.com:
3010 Leuven is de enige correcte schrijfwijze: Leuven is de gemeente,
niet Kessel-Lo.
http://www.bpost.be/adressering/#2
• Gebruik bij voorkeur
2014-11-04 0:07 GMT+01:00 Jo winfi...@gmail.com:
Wat De Post betreft dus wel, ja. Weet jij waar 3018 Leuven is?
Jo
Er is allessinds geen officieel bestand dat aangeeft tot waar Wijgmaal loopt.
___
Talk-be mailing list
Talk-be@openstreetmap.org
Sander,
Ik heb de JSON-bestanden opnieuw aangemaakt met apptnrs en busnrs, deze
keer als echte arrays. Ik zie dat je precies nu bezig bent met wat
wijzigingen. Daarom even acties op elkaar afstemmen om geen conflicten
te veroorzaken. Laat je weten als je een uur geen push zult doen? Dan
Wat die appartement en busnummers betreft, ik heb ook al gevallen gezien
waar het niet eenvoudig is om die te matchen. Zou het kunnen dat het
appartementnummer is, wat er op de bel staat en het busnummer wat je als
uitbreiding van het huisnummer op een enveloppe zou schrijven?
Dat zou dan
Heb nu postcode 1982 gedaan tot en met straten met een T*. Heel veel
werkt, mijn RSI-pols is terug maar we zijn er bijna erdoor.
Er vallen mij wel aantal dingen op.
-1A vs 1a wordt door de tool als fout gemerkt, niet echt een probleem,
ik zet ze allemaal naar de hoofdletter versie, mss wel goed
De appartementnummers en busnummers zijn nu toegevoegd aan de tools. Er
wordt ook gewaarschuwd indien zowel bus- als appartementsnummers aanwezig
zijn. Wees nog voorzichtig met deze tag. Ik heb nog geen tijd gehad om uit
te zoeken welke CRAB onderverdeling nu gebruikt wordt in welk geval.
Ik heb
There's an error at the moment with the importer.
loadStreets.js:276
Uncaught SyntaxError: Unexpected token
import.html?pcode=1982filterStreets=*maxDistance=loadOsm=trueincludePcode=falsecrabInfo=false…:1
..
!--
vim: tabstop=2:softtabstop=2:shiftwidth=2:noexpandtab
--
html
This is on
De overpass-query wordt nu naar de Russische overpass-api gestuurd.
Daarmee functioneert de import-pagina nu eerst weer. Uit de
foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die
Russische api anders is dan die van de Duitse api. Ik heb een check
toegevoegd die daarmee
Het zal wss zijn door de emergency rollback van overpass. Zie subject:
[OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback
Glenn
On 03-11-14 01:32, Thomas wrote:
De overpass-query wordt nu naar de Russische overpass-api gestuurd.
Daarmee functioneert de import-pagina nu eerst
2014-11-01 1:43 GMT+01:00 Thomas o...@aptum.nl:
Voor wat betreft de relaties tussen de huisnummers en straten sluit ik mij
deels aan bij Ben: vanuit mijn informatica-achtergrond ben ik een groot fan
van dit soort relaties. Vanuit mijn ervaringen met niet-informatici weet ik
echter dat dat
Op 1 november 2014 01:43 schreef Thomas o...@aptum.nl:
Je verbeteringen vind ik zeer goed Sander! Bij mij laadt de pagina nu
echter niet, met een foutmelding “'section' is null” op loadstreets.js
~664. Het lijkt fout te gaan wanneer in de URL de GET-parameter
collapsedSections geset wordt,
Op 1 november 2014 10:30 schreef Glenn Plas gl...@byte-consult.be:
Dat is goed bezig een vette tool te worden
Ik zie veel fouten in de buurt, maar allemaal op nummers die ik zelf heb
gemapt, en waarvan ik zeker ben (3 liggen binnen de 100meter). Het
lijkt wel alsof crab vol fouten zit.
Vooraleer iemand in het komende uur of zo een pull of push wil gaan
uitvoeren: ik sta op het punt de nieuwe JSON bestanden te pushen. Het
enige punt waarop ze niet backwards-compatible zijn is het feit dat het
huisnummerlabel nu in een lijst zit. Ik heb de loadStreets.js al
aangepast naar een
Heb nog niks concreet eigenlijk, maar wel paar ideetjes alvast. De
problemen die ik zag zijn zo te zien allemaal ondertussen opgelost.
De wiki handleiding is handig ook. Tijdens het gebruiken heb ik
eigenlijk vooral problemen bij nr notaties van dit type:
vb1:
nr is 100 , bus 4
varianten
Der zit een probleem in de js:
sourceHnr = uniformise(sourceAddr.housenumber);
sourceHnrLabel = uniformise(sourceAddr.hnrlbls[0]);
compHnr = uniformise(compAddr.housenumber);
compHnrLabel = uniformise(compAddr.hnrlbls[0]);
compAddr is not defined, dus
Plas gl...@byte-consult.be
To: OpenStreetMap Belgium talk-be@openstreetmap.org
Sent: Saturday, November 1, 2014 12:31 PM
Subject: Re: [OSM-talk-be] import AGIV CRAB-data
Heb nog niks concreet eigenlijk, maar wel paar ideetjes alvast. De
problemen die ik zag zijn zo te zien allemaal ondertussen
Hooi,
Leopoldsburg heeft 2 zonenummers, 3970 en 3971 (vroeger Heppen).
De Vaartstraat loopt door de 2 zones. Nummers 120 en 134 liggen in 3971,
maar 122,126, 128, 130 en 132 die er tussen liggen vindt men in 3970, wat
fout is, ook volgens Bpost.
Fout dus in CRAB.
Sus
.
From: Glenn Plas gl...@byte-consult.be
To: OpenStreetMap Belgium talk-be@openstreetmap.org
Sent: Saturday, November 1, 2014 12:31 PM
Subject: Re: [OSM-talk-be] import AGIV CRAB-data
Heb nog niks concreet eigenlijk, maar wel paar ideetjes alvast. De
problemen die ik zag zijn zo te zien
Op 1 november 2014 13:12 schreef Thomas o...@aptum.nl:
De nieuwe reeks JSON-bestanden staat inmiddels online.
Bedankt, zal eens kijken als alles nog werkt, en wat er toegevoegd is ;)
Zoals eerder gezegd is de voornaamste wijziging die invloed heeft op de
huidige werking het feit dat
Op 1 november 2014 13:15 schreef Gilbert Hersschens gherssch...@gmail.com:
Ik heb even een poging gedaan. Ziet er wel handig uit, maar bij
appartementen geeft hij een hoop missing nummers op omdat hij geen
rekening houdt met get gebruik van een bereik van nummers. Ik ben eerlijk
gezegd niet
2014-10-31 16:22 GMT+01:00 Sander Deryckere sander...@gmail.com:
Verder heb ik er ook nog een optie aan toegevoegd om te exporteren naar
GPX. Onderaan de tabel vind je drie knoppen om die drie kolommen te
exporteren naar GPX, en zo alle probleemgevallen in je gemeente naar je GPS
of
Het gebeurt in totaal 702 keer over alle adressen (inclusief
subadressen) heen. Daarbij zijn 211 huisnummers betrokken. Op 27 oktober
mailde ik dit daarover:
Verder is er iets bijzonder aan de hand met de huisnummer-labels.
Die worden door het AGIV automatisch opgemaakt per huisnummer,
Thomas,
In je spec staat dat busnummers en appartementnummers arrays zijn, maar in
werkelijkheid lijken het comma-separated strings. Zou je het kunnen
wijzigen naar arrays? Arrays lijken veiliger voor het geval een busnummer
plots ook een komma bevat.
Verder zijn er idd eigenaardige adressen.
Nog wat verder gewerkt aan de tools.
De straten worden nu altijd op een kaartje weergegeven, met een kleurencode
om aan te duiden hoe compleet die zijn. De links in die popup werken zoals
de links in de tabel.
Verder heb ik er ook nog een optie aan toegevoegd om te exporteren naar
GPX. Onderaan
die GPX bestanden gaan zeker van pas komen. hartelijk dank !
m
2014-10-31 16:22 GMT+01:00 Sander Deryckere sander...@gmail.com:
Nog wat verder gewerkt aan de tools.
De straten worden nu altijd op een kaartje weergegeven, met een
kleurencode om aan te duiden hoe compleet die zijn. De links
Sander, Thomas,
op http://aptum.github.io/import.html moet ik nadat ik op 'update' heb
gedrukt, nu een back doen om de data te zien.
platform Chrome op OSX.
veel debug plezier (niet zonder leedvermaak, na een dag van bug hunting op
het werk :-) )
2014-10-31 17:54 GMT+01:00 Marc Gemis
Zou het een idee zijn om ook de gebouwen voorzien van een fixme aan zo'n
GPX-bestand toe te voegen?
Dan kunnen we ook via die weg terugkoppelen dat extra survey nodig is, in
geval van twijfel.
ook de adressen waar wij zeker van zijn, maar die anders in crab zitten
zouden we van een tag kunnen
Marc, die bug moet ondertussen opgelost zijn.
Jo, dat is idd een optie. Maar ik vraag me af als het wel in deze tool
past. De fixme gaat in veel gevallen niet over het adres, maar ook over de
naam van de winkel, de openingsuren, ... Daarnaast zijn er ook veel fixmes
die wel moeten opgelost zijn,
Je verbeteringen vind ik zeer goed Sander! Bij mij laadt de pagina nu
echter niet, met een foutmelding “'section' is null” op loadstreets.js
~664. Het lijkt fout te gaan wanneer in de URL de GET-parameter
collapsedSections geset wordt, maar zonder waarde blijft. Als ik die
parameter handmatig
mee kunnen want dat zijn de mensen die meestal het meest tijd hebben om
‘veldwerk’ te doen.
GuyVV
Van: Marc Gemis [mailto:marc.ge...@gmail.com]
Verzonden: donderdag 30 oktober 2014 11:11
Aan: Jo Simoens; OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] import AGIV CRAB-data
Jo
.
GuyVV
*Van:* Marc Gemis [mailto:marc.ge...@gmail.com]
*Verzonden:* donderdag 30 oktober 2014 11:11
*Aan:* Jo Simoens; OpenStreetMap Belgium
*Onderwerp:* Re: [OSM-talk-be] import AGIV CRAB-data
Jo, jammer genoeg ben je nog zo wat de enige die nog met associatedStreet
relaties wil werken. Als
Ik deel die mening ook over die relaties. En zeker over interpolation
van adressen in Belgie springt het van tijd wel heel hard, ik weet een
straat waar huizen naast elkaar opeenvolgende nummers krijgen, bv
1,2,3,4,5 8 Dus geen even/oneven verdeling zoals we gewoon zijn.
Geocoding werkt
Ziehier een prachtvoorbeeld van hoe scheef het kan lopen:
https://www.openstreetmap.org/relation/1523419/history
https://www.openstreetmap.org/relation/1523417/history
https://www.openstreetmap.org/relation/1524225/history
Maar wat wil je dan op een grens tussen de provincies...
Vooral deze
2014-10-30 13:13 GMT+01:00 Jo winfi...@gmail.com:
Vooral deze huizen (14 en 15) lijken mij bijzonder lastig om te vinden:
Mooi voorbeeld, 14 en 15 op googlemaps:
https://www.google.be/maps/place/Langestraat+15,+3128+Tremelo
https://www.google.be/maps/place/Langestraat+14,+3128+Tremelo
Haha!
Vul nu Langestraat 14, Baal (daar moet ze toch inliggen niet ?) in op
osm.org of nominatim.openstreetmap.org
Ik geloof niet dat daar het gewenste resultaat uitkomt. Of wel ? (het
resultaat is: House 14, Schrieksesteenweg, Baal, Flanders, 3128, Belgium)
Leg dat maar eens uit een een beginnende
Natuurlijk zijn er problemen met adressen. Iedereen kent probleemadressen.
Maar werken met relaties zorgt ongetwijfeld voor fouten (iedereen maakt
fouten). Het wordt enkel maar erger als je 200 relaties moet onderhouden
voor 1 gemeente. Terwijl je hier ook, voor alle gevallen de gegevens
perfect
2014-10-30 14:02 GMT+01:00 Marc Gemis marc.ge...@gmail.com:
Langestraat 14, Baal
Vreemd toch die nominatim: Langestraat 14, Tremelo werkt dan weer wel! (op
osm.org op de nominatim-website dan weer niet)
Ik heb nominatim altijd een vreemd beest gevonden. Het is volgens mij of
een kwestie van
2014-10-30 14:31 GMT+01:00 Ben Abelshausen ben.abelshau...@gmail.com:
Langestraat 14, Tremelo
Nominatim gebruikt de associatedStreet enkel en alleen om een straatsegment
te zoeken. Het neemt gewoon de eerste street in de relatie (verklaart
misschien de afwijkende resultaten op de 2 sites, als
Probeer eens op deze:
http://nm1.bitless.be/
Is een oudere export met eigen customizations van mezelf.
Glenn
On 30-10-14 14:46, Marc Gemis wrote:
2014-10-30 14:31 GMT+01:00 Ben Abelshausen ben.abelshau...@gmail.com
mailto:ben.abelshau...@gmail.com:
Langestraat 14, Tremelo
Deze ookal:
http://maps.skobbler.com/?country=Belgiumcity=tremelostreet=Langestraatnumber=14lat=51.0244385lon=4.7465014z=16
Met vriendelijke groeten,
Best regards,
Ben Abelshausen
___
Talk-be mailing list
Talk-be@openstreetmap.org
Ik speel al lang met het idee om een light weight straightforward
geocoder te maken omdat nominatim te zwaar is, de hele PHP code is
vergeven van uitzonderingen , afhankelijk van welke diepte level je zit.
5 jaar geleden moest ik de postcodes er nog bijhacken omdat die voor
belgie niet meekwam
Bon,
De CRAB herkomst staat nu altijd als odbl:note=CRAB:xxx, en kan dus
gebruikt worden in de CSS.
De webpagina is ook aangepast met twee extra opties. Zo kan je nu de CRAB
herkomst ook zichtbaar meekrijgen (voor degene die het willen bekijken), en
kan je ook de postcode als tag toevoegen. Let
Wil je beide lijsten (busnrs en apptnrs) los in de JSON hebben, of
samengevoegd als “subadressenlijst”? Ik had het als dat laatste al
ingebouwd, maar ik kan het natuurlijk eenvoudig weer uit elkaar trekken.
De lijsten worden toch al los van elkaar opgebouwd.
Groeten,
Thomas
Sander Deryckere
Ik heb het script nu verder uitgerust met een aantal
data-integriteits-checks rond postcode / gemeente. Daaruit blijken toch
nog wat bijzondere dingen waar ik het script op moet aanpassen. Zo
blijkt dat een straat (zoals geïdentificeerd door zijn ID in de
adressenlijst) in meerdere postcodes
Misschien beter om de lijsten van appartementsnummers en busnummers te
splitsen. Zelf begrijp ik het verschil nog niet goed, maar als we het
eenmaal begrijpen, dan moet de data tenminste niet opnieuw gegenereerd
worden.
Op 29 oktober 2014 19:52 schreef Thomas o...@aptum.nl:
Ik heb het script
2014-10-29 20:37 GMT+01:00 Sander Deryckere sander...@gmail.com:
Zowel de postcodes als de gemeentes worden op basis van grenzen getekend.
De straten als lijnen die binnen bepaalde van die grenzen liggen, en de
adressen als punten die ook binnen bepaalde van die grenzen liggen.
Aangezien dit
Veel van de adressen die als wrong worden aangegeven, zijn gewoon 8a ipv
8A. De vraag is nu standardiseren we op hoofdletters voor die letters, of
maken we het script hoofdletterongevoelig?
Jo
Op 28 oktober 2014 00:07 schreef Sander Deryckere sander...@gmail.com:
Wat de afwijking in Ieper
Voor zover ik zie, zijn er 2 mogelijke bisnummer formaten in CRAB. Deze met
alfabetische en deze met numerieke toevoegingen.
Voor zover ik gezien heb, worden de alfabetische toevoegingen altijd als
een hoofdletter geschreven, zonder scheidingssymbool (dus 7A en niet 7a
of 7 A). De numerieke
2) CRAB:message. Deze bevat informatie over het al dan niet aanwezig zijn
van busnummers en appartementnummers op dat specifieke adrespunt. Deze
gegevens hoeven niet in OSM opgenomen te worden maar kunnen (zeker nu in de
testfase) verhelderend werken.
Er is een addr:flats tag die kan gebruikt
Ik heb mij bezig gehouden met het maken van unit tests. De vele regexen
zorgden vaak voor bugs die al eens vroeger opgelost waren.
Er is ondertussen ook ondersteuning voor bis, ter en /1, /2, ...
Ook straatnamen met een streepje verschil (Sint-Jansstraat en Sint
Jansstraat) worden nu vergeleken.
Over het beschikbaar maken van postcode en gemeentenaam: de postcode
wordt reeds meegegeven in de JSON bestanden en de gemeentenaam kan
daaraan worden toegevoegd. Met twee regels code heb ik dat voor elkaar.
Echter, daarbij moet ik wel de nodige extra checks inbouwen voor de
gemeente-id en de
Hooi,s
Bij de Balen Neetlaan wordt alles als missing opgegeven al is bijna alle
in orde met de goede zonenummers. De huizen met pare nummers staan op Mol
2400, de onpare staan op Balen 2490. Voor beide gemeenten draagt de baan
dezelfde naam. De gegevens komen wel fatsoenlijk binnen in JOSM.
Bij
Op 27 oktober 2014 16:58 schreef Sus Verhoeven sus...@gmail.com:
Hooi,s
Bij de Balen Neetlaan wordt alles als missing opgegeven al is bijna alle
in orde met de goede zonenummers. De huizen met pare nummers staan op Mol
2400, de onpare staan op Balen 2490. Voor beide gemeenten draagt de baan
Inmiddels ben ik weer een heel stuk verder met het script. De memoryload
heb ik terug kunnen brengen tot 1,1GB. De looptijd zit nu net boven een
uur. Dat komt vooral omdat ik een aantal extra checks heb toegevoegd.
Daarmee kan de integriteit van de data wat beter vastgesteld worden, nu
en in
Ik heb in JOSM de display.discardable-keys eens even terug op false gezet.
MapCSS blijft deze wel tonen, ook al verschijnen ze dan niet meer in de
Properties aan de rechterkant.
Het beste van 'both worlds' lijkt me. Ze staan uit het zicht, worden zeker
niet doorgestuurd naar de server en wie ze
Bedankt voor de updates, lijkt veelbelovend. Die extra statistieken kunnen
idd handig zijn.
Op 27-okt.-2014 22:27 schreef Thomas o...@aptum.nl:
Inmiddels ben ik weer een heel stuk verder met het script. De memoryload
heb ik terug kunnen brengen tot 1,1GB. De looptijd zit nu net boven een
uur.
Wat de afwijking in Ieper (8900) betreft, het enige wat in mij opkomt is
dat er een dikke 2 jaar geleden een grootschalige hernoem actie was:
http://nieuwsblad.be/cnt/DMF20120213_113
Dat de huisnummers daardoor foutief zijn lijkt me iets heel eigenaardigs.
Buiten Ieper herken ik geen specifieke
Sander of anderen,
In Balen 2490, Hoolst zijn er plaatsen met een nummer op het gebouw en
een ander nummer op het perceel.
Moet ik hier de anomalieën in CRAB nog melden ?
Sus
___
Talk-be mailing list
Talk-be@openstreetmap.org
De validator geeft inderdaad netjes melding van de meerdere punten op
elkaar. Ik vraag me af of we daar nog iets mee moeten. Veel (alle?) van
de adressen zonder positie uit jouw script vallen nu samen met een ander
punt. Voor wat ik zo snel even kon bekijken zijn dat toch best veel
punten.
Op 26 oktober 2014 10:11 schreef Verhoeven Fr sus...@gmail.com:
Sander of anderen,
In Balen 2490, Hoolst zijn er plaatsen met een nummer op het gebouw en
een ander nummer op het perceel.
Moet ik hier de anomalieën in CRAB nog melden ?
Sus
Heb wat documentatie begonnen op de wiki
Op 26 oktober 2014 10:20 schreef Thomas o...@aptum.nl:
De validator geeft inderdaad netjes melding van de meerdere punten op
elkaar. Ik vraag me af of we daar nog iets mee moeten. Veel (alle?) van de
adressen zonder positie uit jouw script vallen nu samen met een ander punt.
Voor wat ik zo
Voor tags waarvan je niet wilt dat ze naar OSM worden opgeladen is het het
beste om tags te gebruiken die automatisch zullen worden verwijderd,
voorbeelden zijn created_by en odbl. Laat me weten als er meer nodig zijn.
Ze zitten ergens in de broncode van JOSM.
Ik zou dus die tags gebruiken ipv
Thomas, nog 1 opmerking.
De pcode.json bestanden waren gesorteerd per naam (sanName om precies te
zijn), en de straat.json bestanden werden lexicografisch volgens huisnummer
gesorteerd (11-12-13-2-20-...).
Dit is om dat op die wijze diffs in de toekomst meer zin zullen maken (en
het formaat
Het lijkt mij ook aangewezen om voor de nummers die in de wronglaag worden
geladen geen addr:housenumber/addr:street te gebruiken. Daar zou ik enkel
discardable keys gebruiken, die we dan zichtbaar maken mbv MapCSS. (Wel
Expert modus gebruiken, anders worden ze niet getoond)
Zo ontstaat er geen
Op de Goudfazantenlaan in Heverlee wordt 5A als missing aangegeven. Dat
nummer is er echter wel in OSM, maar dan als 5a. Willen we dit
standaardiseren op allemaal hoofdletters, of willen we dat
hoofdletterongevoelig houden?
Jo
Op 26 oktober 2014 11:09 schreef Jo winfi...@gmail.com:
Voor tags
De herkomst voor de punten die in mijn script samenvallen is
vaak/meestal/altijd onderling niet verschillend, noch wijkt die herkomst
af van de andere punten in de straat. Het gaat sowieso niet om
busnummers / appartementnummers. Die heb ik net als in jouw script niet
opgenomen. Het gaat
Zo, even wat kwalitatief onderzoek gedaan:
* De kwaliteit van de adressenlijst is over het algemeen beter, maar voor
enkele huizen is het ook slechter. Zo heb ik de Ieperstraat in Staden
(8840) bekeken, daar werd voor bepaalde huizen de positie in de
adressenlijst net verder van de straat gezet
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
Op 25 oktober 2014 09:21 schreef Verhoeven Fr sus...@gmail.com:
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
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,
Op 25 oktober 2014 10:55 schreef Gilbert Hersschens gherssch...@gmail.com:
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
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 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
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
Op 25 oktober 2014 14:48 schreef Sus Verhoeven 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
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
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
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 sus...@gmail.com:
Le 25/10/14 16:11, Sander Deryckere
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
1 - 100 of 172 matches
Mail list logo
