Preliminary attempt at deducing the upload procedure from the code (Danish)

[mikini]

1. osmdata-{add,change}.php

• Et cron-job eksekverer disse med php cli-kommandoen en gang pr. postnummer, med postnummeret som parameter.
• Det fylder for hvert postnummer en række i den respektive MySQL-tabel med OSM XML[1]-formatterede node-objekter efter sammenligning mellem OSM og DAWA.
• Cron-jobbet må være drevet af et script der itererer igennem en liste af postnumre, eller bliver fodret med start og stop postnummer, og anvender det mystiske "Næste postnummer"-output (som egentlig er forrige) fra scriptet ved næste kald til at bevæge sig nedad fra slut til start.

2. osmdata-add-output.php

• Eksekveres en gang når databasen indeholder data fra de postnumre man ønsker at uploade til OSM, med Apache og mod_php via et HTTP-request.
• Dette indlæser alle rækker med postnumre fra den osmadd MySQL-tabellen, og genererer en samlet OSM XML-struktur som tilbydes til download i HTML'en via et link til en indlejret "add_.osm"-fil.

3. osmdata-change-output.php

• Eksekveres en gang pr. postnummer hvis indhold i databasen man ønsker at uploade til OSM, med Apache og mod_php via et HTTP-request hvor postnummer angives i GET-parameteren 'postnummer'.
• Dette indlæser rækken med det givne postnummer fra osmchange MySQL-tabellen, og genererer en OSM XML-struktur som tilbydes til download i HTML'en via et link til en indlejret "change_.osm-fil som gemmes lokalt på brugerens disk.

4. Upload til OSM via JOSM

• De genererede .osm-filer indlæses i passende mængder i JOSM, inspiceres, valideres og endelig uploades via OSM API'et[2].

Et par alvorlige konkrete problemer observeret undervejs:

• det ser ud som om add-scriptet kun gemmer én node (den sidste) der er analyseret som tilføjet pr. postnummer, da den ikke bevarer data i $textexport2 under iterationen over data (?!)
• i databasen erstattes '-tegnet med #-tegnet uden escaping, dette vil give problemer hvis data indeholder #, da disse så også fejlagtigt vil blive erstattet