[Talk-dk] Adresser på nye veje - og andet godt nyt

Peter Brodersen peter at ter.dk
Ons Maj 12 04:54:29 BST 2010


Hej,

Allerførst: Yep, der bør wiki'es en del, specielt nu hvor der er en del
forskellige opdaterings-projekter kørende. Det kommer også til at ske.

Dernæst: Jeg har fået kodet lidt videre på projektet og opdateret en god del
adresser. Her er et screenshot af systemet, som en lille forsmag:
http://osm.ter.dk/streetupdate.png
Systemet fortæller altså, hvad den har tænkt sig at gøre med de enkelte
adresser (markeret med grønt, gult eller rødt) - eller hvorfor, den vil
undlade at gøre noget ved en adresse (markeret med blåt).

De gode nyheder:
- Jeg har fundet en stabil XAPI-tjeneste. Jeg kan ikke både søge på
kommunekode+vejkode, så jeg nøjes med at søge på vejkode (de er typisk på
fire cifre, så den samme vejkode optræder for mange forskellige veje i
forskellige kommuner) - dvs. værdien for kms:street_no - og så i det store
output filtrerer jeg bare indholdet på min side. Langt fra optimalt, men det
tager stadigvæk kun et par sekunder.
- Det nye dataudtræk har fået processen til at virke :-) Ved at sammenholde
OSAK-data med OSM-data er det let at se hvilke adresse-noder, som skal
tilføjes, rettes, slettes eller ignoreres.
- Performance er generelt ret god. Det tager en 5-10 sekunder at hente de to
datasæt (OSAK og OSM), og hver node-opdatering i OSM tager ca. et sekund
(dvs. et minut eller to for en stor vej). Jeg har overvejet at kigge på
osmChange for at lave én samlet opdatering; det burde gå endnu hurtigere.
- Opdateringer skriver nu navnet på den behandlede vej på i
changeset-kommentaren.
- Programmet kan også rette postnummer+by til, hvis de er skiftet i
mellemtiden. Det er fx tilfældet her for en lang række nodes her, der er
skiftet fra 2860 Søborg til 2870 Dyssegård:
http://www.openstreetmap.org/browse/changeset/4674155
Den ændring er faktisk noget, mit enkelt-node-opdaterings-program (
http://osm.ter.dk/address_insert.php ) ikke foretager, men det burde den
også. Det er ikke noget, jeg har tænkt på før jeg faldt over et sådan
tilfælde her i nat.
- Der er allerede opdateret ca. 200 veje ved hjælp af programmet - inklusive
en del nye adresser på de veje.

De dårlige nyheder:
- Noget af en showstopper: Grundet kommunalreformen har en god del adresser
skiftet vejkode og kommunekode! Det er den største forklaring på, at
værktøjet endnu ikke er online, idet man kan skabe en del problemer med det.
Mere om det længere nede.
- Programmet kan ikke slette nodes endnu. Indtil videre bliver de bare
ignoreret, når en vejs indhold skal opdateres. Jeg kan ikke lige lure,
hvordan man med PHP og cURL kan lave et DELETE-request *med* XML-indhold.
Jeg må spørge lidt rundt omkring.
- XAPI-fortegnelsen er lidt forsinket. Det betyder, at hvis man går ind på
en vej, man lige har opdateret, kan man hente forældet data. Det gør ikke så
meget for adresser, der bare skal opdateres (de bliver bare overskrevet med
den samme data) eller sletninger (noden er allerede slettet, så endnu en
sletning gør ingen forskel), men nyoprettelser kan ske igen, idet der ikke
er noget node-id at forholde sig til her. Er der egentligt ikke noget med at
OSM brokker sig, hvis en ny node bliver oprettet på samme position som en
eksisterende?

Det største problem er det med kommune/vejkoderne. Det er så et rimeligt
stort problem, idet den gamle kommunalkode+vejkode for en vej ikke stemmer
overens med det nye sæt.

Det betyder, at man kan søge og finde en vej og få koordinater fra OSAK med
en kommune+vejkode, som der ikke findes noget på i forvejen i OSM. Her vil
mit program så foreslå, at den opretter samtlige adresser. Søger man derimod
på de gamle koder (som ikke længere findes i OSAK), vil mit program foreslå
at slette alle de gamle adresser.

Gør man begge dele, er der måske som sådan ikke noget problem, men det er
stadigvæk lidt noget rod - specielt fordi der ikke er nogen automatisk måde
at gøre det må.

Problemet er altså, at der ikke er en garanteret måde, jeg kan få det
korrekte datasæt fra OSM. Jeg har overvejet nogle alternativer, men de er
ikke rigtigt gode. Det vil ikke virke at hente/filtrere/sammenligne på
vejnavn og postnummer, idet en vej kan spænde over flere postnumre, plus at
adresser i nogle tilfælde har skiftet postnummer i mellemtiden (men bevaret
kommune/vejkode). Det er fx tilfældet med førnævnte nodes, som skiftede fra
2860 Søborg til 2870 Dyssegård. I det tilfælde var mit
sammenligningsgrundlag således kun kommunekode+vejkode+husnummer for at
konkludere, at der var tale om de samme adresser i de to sæt.

Det holder heller ikke at sætte en spærring ind, hvis programmet kun vil
oprette nye adresser. Flere nye veje er netop tilføjet på den måde, som set
på:
http://www.openstreetmap.org/browse/changeset/4655604
Det er netop også en ret effektiv måde at få et overblik over omfanget af en
ny vej, man endnu ikke har mappet.

Jeg har ikke selv en vildt god løsning på problemet i baghovedet. Mit script
er endnu ikke frit tilgængeligt, idet det er let at komme til at slette en
masse adresser eller oprette en række dubletter i de kommuner, som skiftede
kommunekode i forbindelse med kommunalreformen. Er du alligevel
interesseret, så spring på IRC og hiv fat i mig (brugernavn: pbro):
irc://irc.oftc.net/osm-dk
For mange byer er værktøjet sikkert nok at bruge. Det er mere, hvis noget
mod forventning skulle gå galt, eller du vil hjælpe med udviklingsarbejdet.

- Peter Brodersen


2010/5/10 Peter Brodersen <peter at ter.dk>

> Hej,
>
> Lige et par gode nyheder herfra på mit arbejde med at opdatere
> adresse-koordinater.
>
>
> 0. Forklaring af forkortelser
> 1. Opdatering af hele veje
> 2. "AWS request error" gennemskuet
> 3. Ændring i opdateringskøen
>
>
> 0. Forklaring af forkortelser
>
> OSM: OpenStreetMap (-data)
> KMS: Kort- og Matrikelstyrelsen. I denne sammenhæng henviser KMS til det
> datasæt med millioner af danske adresse-koordinater, der blev frigivet
> omkring 2002 og som er lagt ind i OSM.
> OSAK: Officielle standardadresser og koordinater. Henviser til de
> standardiserede og løbende opdaterede adressedata, vi er interesseret i
> :-)
> AWS: Address Web Services. En SOAP-baseret webtjeneste, der giver mulighed
> for at forespørge om data. Metoderne er offentligt tilgængelige, gratis at
> anvende og der er ikke restriktioner på den videre anvendelse af output.
>
> KMS og OSAK er altså adressesæt fra det offentlige. AWS er metoden, anmoder
> om adressedata på.
>
>
> 1. Opdatering af hele veje
>
> For det første er jeg ved at teste nye funktioner til at opdatere hele veje
> i stedet for blot enkelte koordinater. Fordelen er, at vi får et hurtigere
> udtræk (mange koordinater på én gang), og at vi får et udtømmende udtræk for
> en vej. På den måde kan vi både oprette nye adresser og opdatere
> eksisterende i samme omgang, hvilket er en klar forbedring for den nuværende
> opdaterings-metode, hvor vi kun tjekker eksisterende adresser (fra det
> oprindelige KMS-input).
>
> Jeg testede lidt i nat med Jonas (rasher). Et par af opdateringerne kan ses
> her:
> http://www.openstreetmap.org/browse/changeset/4655604
> http://www.openstreetmap.org/browse/changeset/4655607
> http://www.openstreetmap.org/browse/changeset/4655731
>
> Programmet er endnu ikke i fri drift (grundet de problemer, jeg nævner
> længere nede), men det virker på følgende måde:
> 1. Man indtaster et vejnavn og ud fra en liste af veje i Danmark med det
> navn (hentet via AWS) vælger man den ønskede vej, man vil have opdateret
> 2. Programmet bruger den valgte vejs kommunekode+vejkode til at anmode om
> en liste af OSAK-data via AWS
> 3. Programmet henter en tilsvarende liste fra OSM over eksisterende veje
> 4. Programmet sammenligner de to lister (OSAK og OSM), og foretager
> følgende handlinger i OSM:
> 4.1. Findes adressen kun i OSAK, bliver den oprettet med alle addr:-felter
> og OSAK-data (id, kommune+vejkode, revision)
> 4.2. Findes adressen både i OSAK og i OSM, bliver den opdateret med
> koordinater og OSAK-data (id og revision)
> 4.3. Findes adressen kun i OSM, bliver den slettet.
>
> Den nuværende ulempe er, at det er svært at trække data ud af OSM! Jeg
> ville gerne bruge XAPI til adresse-prædikater, fx:
>
> http://www.informationfreeway.org/api/0.6/node[kms:municipality_no=615][kms:street_no=1938]
> Men dette giver problemer, idet den ene XAPI-tjeneste kun giver mulighed
> for at begrænse sit opslag til ét tag-prædikat (og et bbox-prædikat). Den
> anden tjeneste giver fin mulighed for at begrænse på flere tags, men virkede
> ret ustabil i nat. Før der er fundet en løsning på dette, kan programmet kun
> oprette nye adresser - hvilket kun er brugbart på veje uden nogen som helst
> eksisterende adresser.
>
> Jeg overvejer en alternativ løsning med en lokal database af
> adressepunkter. Jeg henter alligevel et dagligt udtræk. Men det ville være
> rart, hvis tjenesten kunne spørge op imod den rigtige database med det
> reelle indhold. Ellers risikerer at programmet flere gange prøver at oprette
> nye vejpunkter, fordi den ikke kan se, at punkterne er blevet oprettet.
>
> En let metode mod dette er at logge lokalt, hvilke veje, som er blevet
> opdateret, men netop fordi der løbende kan komme opdateringer til (nye
> adresser, nedlagte adresser, mere præcise adresser), skulle folk helst kunne
> have mulighed for at opdatere den samme vej flere gange over tid.
>
> Der er en del mere, som skal finpudses på programmet. Den overholder
> allerede de sædvanlige regler - primært at hvis en node er blevet
> modificeret siden KMS-importen, holder den snitterne væk. Et alternativ til
> at slette et modificeret punkt (fx hvis der er tilføjet en butik til
> adressepunktet), som ikke er i OSAK, kunne være bare at fjerne alle
> adresse-tags og bevare den tilføjede information. Således bliver et
> adressepunkt med en butik og navn tilføjet blot reduseret til butikken og
> navnet, og ingen adresse-data.
>
> Slutteligt skal der gøres en del ved overskueligheden, så man lettere kan
> se, hvad scriptet har tænkt sig at gøre, før man trykker OK.
>
> Kender I til veje, hvor der ikke er nogen som helst adressepunkter, så giv
> endelig lyd - dem kan jeg snildt tilføje.
>
>
> 2. "AWS request error" gennemskuet
>
> Der har tidligere været problemer med adresser, som gav problemer i AWS.
> Det er dem, som fremstår som "AWS request error" på kø-oversigten:
> http://osm.ter.dk/address_insert.php
> I første omgang var det blot en kategori for ethvert AWS-opslag, som gav en
> eller anden form for fejl.
>
> Nogle af dem har været forståelige nok, som når AWS brokker sig over
> adresser som denne:
> http://www.openstreetmap.org/browse/node/340946635
> .. på adressen "Hillerødvej 902, 0000 Uoplyst" :-)
>
> I adskillige andre tilfælde var der blot tale om at mit script kun havde
> tålmodighed til at vente 60 sekunder på et svar. Denne timeout-værdi er nu
> hævet godt deropad. Nogle opslag har taget op til 15 minutter - og det altså
> bare for en enkelt adresse!
>
> AWS-fejl-adresserne blev smidt til gentest kort efter jeg hævede
> timeout-indstillingen, og de ca. 20.000-adresser, som tog lang tid at slå
> op, er nu smidt i kø til gentest. Det virker således som adresser, som
> AWS-systemet bruger lang tid at slå op, så der går nok lidt tid, før den del
> af køen er tygget igennem
>
>
> 3. Ændring i opdateringskøen
>
> I samme omgang har jeg ryddet lidt op i køen, blandt andet så
> adressepunkter ikke kan optræde flere gange i køen. Oprindeligt var tanken
> at man kunne sætte punkter til gentest, hvis der fx var AWS-problemer,
> OSM-problemer eller at jeg tweakede på andre ting. Men det skabte blot lidt
> forvirring over hvor mange forskellige punkter, der var blevet behandlet. Nu
> indsætter køen kun node-id's, hvis de ikke findes i tabellen i forvejen.
>
>
> - Peter Brodersen
>
>
-------------- næste del --------------
En HTML-vedhæftning blev fjernet...
URL: <http://lists.openstreetmap.org/pipermail/talk-dk/attachments/20100512/92b5a461/attachment.html>


More information about the Talk-dk mailing list