Og en afrunding herfra: Vi lavede en opdatering den 2. maj, hvor der ligeledes var en upload, som stoppede op undervejs, ryddede op, og har så tilføjet de sidste bygninger i dag.
Indtil videre er metoden at tage mindre segmenter af gangen, så alt inden for et område kan uploades atomisk i én changefil. Derudover snakker jeg med kommunen om at få flere kommuner med. - Peter 2013/5/1 Peter Brodersen <[email protected]> > Lige en opdatering herfra; > > Jeg har fjernet oceaner af de tomme punkter, så de skulle snart være væk > igen. > > Geofabrik, som vi bruger til at hive store udtræk fra, havde ikke > tidligere i dag fået opdateret data med alle de nye bygninger, vi havde > lagt ind. Derfor kunne vi ikke lave en frisk sammenligning for at se, hvor > vi manglede at lægge bygninger ind. > > Vi regner med, at det er tilfældet i morgen, hvor vi kigger på det igen. > > - Peter > > > 2013/5/1 Peter Brodersen <[email protected]> > >> Hej Ivar, >> >> Da jeg var ved at uploade de sidste filer, undlod serveren at svare. >> Problemstillingen er lidt, at vi uploader større mængder data, end API'et >> accepterer i én anmodning, så det skal gøres i flere (uafhængige) >> anmodninger, og derfor bliver uploaden ikke atomisk. Den risiko vil altid >> være til stede, sådan som OpenStreetMaps API er opbygget pt. uden >> transaktioner over flere uploads. Changesets er ikke atomiske i sig selv >> (et changeset kan rumme flere uafhængige uploads), og changesets har >> stadigvæk en max-begrænsning på 50.000 elementer, hvorfor der under alle >> omstændigheder skal uploades hen over flere changesets. >> >> Sådan som data typisk er struktureret, bliver alle nodes først uploadet, >> så alle bygninger (afhængig af de nodes) og så alle relationer (afhængig af >> bygninger og nodes). Når denne stopper halvvejs undervejs er der således >> blot uploadet en masse nodes. Problemet er dog begrænset, idet disse nodes >> er lette at identificere, og blot bør slettes. Langt de fleste validatorer >> vil gøre opmærksomme på, at der er nodes uden tags, og typisk er der ingen >> grund til ikke bare at slette disse. I mange andre tilfælde har jeg >> ligeledes slettet andres gamle uforbundede nodes uden tags. >> >> Jeg vil selv tjekke mistænkte områder igennem og slette de nodes, så der >> burde være ryddet pænt op. Uafhængigt af det tjekker vi så for hvilke >> bygninger, vi mangler, og igangsætter så uploaden igen. >> >> - Peter Brodersen >> >> >> >> >> 2013/5/1 Ivar Madsen <[email protected]> >> >>> ** >>> >>> Hej >>> >>> >>> Godt arbejde. >>> >>> >>> Jeg læser din mail som at i ikke har konstateret at der er bygninger som >>> ikke er kommet med, men bare antager at det er. >>> >>> >>> Prøv at kik her >>> http://www.openstreetmap.org/?lat=55.83727&lon=11.96544&zoom=17&layers=M >>> >>> der er der fyldt af tilsyndeladene tomme noder, sikkert opstået ved den >>> fejl som du nævner. >>> >>> >>> >>> -- >>> >>> >>> Med venlig hilsen >>> >>> >>> Ivar Madsen >>> >>> Onsdag den 1. maj 2013 03:21:50 Peter Brodersen skrev: >>> >>> >>> > Hej, >>> >>> > >>> >>> > Så er der bygninger i Frederikssund Kommune på OpenStreetMap! >>> >>> > >>> >>> > Jeg prøvede en række løsninger, men ingen virkede rigtig optimale med >>> at >>> >>> > arbejde på store datasæt. I stedet fik jeg altid vakse Jonas Häggqvist >>> >>> > (rasher) til at hjælpe, og han lavede en opdeling på de bygning-data, >>> vi >>> >>> > har modtaget, til henholdsvis overlappende og ikke-overlappende >>> bygninger, >>> >>> > i .osm-format med relevante tags og ID for bygningerne. >>> >>> > >>> >>> > Jeg har nu importeret (næsten) alle filerne for ikke-overlappende >>> >>> > bygninger, og det er noget, der er tydeligt i hele kommunen - fx >>> >>> > Frederikssund: >>> >>> > >>> http://www.openstreetmap.org/?lat=55.84378&lon=12.05713&zoom=16&layers=M >>> >>> > >>> >>> > De fleste bygninger er importeret, men vi skal lige køre >>> sammenligningen >>> >>> > igen i morgen, idet OSM-serveren, der blev uploadet til, ikke altid >>> gav en >>> >>> > tilbagemelding om data var blevet modtaget korrekt. Der kan derfor >>> >>> > stadigvæk mangle ca. en 5-10 % af bygningerne, men dem lægger vi ind >>> her en >>> >>> > af dagene. >>> >>> > >>> >>> > Derefter er der en række overlap-filer, vi nok gerne vi pudse folk til >>> at >>> >>> > kigge på. Det burde være en overkommelig opgave med fx JOSM's >>> validator at >>> >>> > sammenligne med eksisterende data og fjerne de overflødige bygninger >>> eller >>> >>> > overføre tags. Mere om det senere. >>> >>> > >>> >>> > Men ellers lader det til, at vi er ved at have fået styr på metoden på >>> at >>> >>> > sammenligne datafiler med bygninger op imod eksisterende OSM-data, så >>> vi en >>> >>> > anden gang (fx for hele landet med FOT-data med afklaret licens) kan >>> lave >>> >>> > en kæmpestor import - og samtidig lave selvstændige "konflikt-filer" >>> for >>> >>> > lige præcis de bygninger, som overlapper eksisterende bygninger. Så kan >>> >>> > folk fx hente en pakke for et område og løse overlappet. >>> >>> > >>> >>> > Importen er i øvrigt dokumenteret på wikien: >>> >>> > http://wiki.openstreetmap.org/wiki/Da:Frederikssund >>> >>> > >>> >>> > - Peter Brodersen >>> >>> > >>> >>> > >>> >>> > >>> >>> > 2013/4/23 Peter Brodersen <[email protected]> >>> >>> > >>> >>> > > Hej, >>> >>> > > >>> >>> > > For ca. en måned siden importerede jeg bygninger for Jammerbugt >>> Kommune. >>> >>> > > >>> >>> > > Jeg har nu også modtaget bygninger fra Frederikssund Kommune, og jeg >>> har >>> >>> > > brug for lidt hjælp til planlægning af importen. >>> >>> > > >>> >>> > > Jeg har allerede nu lavet en række .osm-filer til import: >>> >>> > > http://osm.ter.dk/data/frederikssund/osm/ >>> >>> > > .. men der er to problemstillinger, jeg kæmper med - primært ud fra >>> ikke >>> >>> > > at importere bygninger over eksisterende bygninger: >>> >>> > > >>> >>> > > 1. Bygningerne er godt spredt over hele Frederikssund, og der skal >>> >>> > > hentes >>> >>> > > en stor mængde data for at tjekke, at de ikke overlapper. >>> >>> > > >>> >>> > > 2. Der er rigtig mange bygninger tegnet ind i forvejen i >>> Frederikssund. >>> >>> > > Det er i forhold til OpenStreetMap ikke en dårlig ting; tværtimod! >>> Det >>> >>> > > betyder dog, at der kommer til at være noget arbejde med at overføre >>> >>> > > eksisterende egenskaber til de nye bygninger. >>> >>> > > >>> >>> > > Mit udgangspunkt (og hvad jeg har kunnet se) er, at bygningerne fra >>> >>> > > kommunen er bedre i forhold til præcisionen, men mangelfulde i >>> forhold >>> >>> > > til evt. meta-data (butik, navn, åbningstider, wifi, etc.). >>> >>> > > Informationen fra kommunen er begrænset til bygning og evt. type >>> (åben >>> >>> > > eller lukket gylletank/silo). >>> >>> > > >>> >>> > > Det betyder, at der skal tjekkes en del manuelt. Det er som sådan >>> også >>> >>> > > en >>> >>> > > fin ting. >>> >>> > > >>> >>> > > Så spørgsmålet er, hvordan vi lettest får importeret dem alle. >>> >>> > > >>> >>> > > - Vi kunne gøre det i fællesskab. Eventuelt med en wiki-page, hvor >>> folk >>> >>> > > bød ind på en .osm-fil, de ville importere, og efterfølgende >>> opdaterede >>> >>> > > wiki-siden, så vi kan sikre, at folk ikke laver dobbelt-arbejde. >>> >>> > > >>> >>> > > - Jeg kunne muligvis få mit program til at sortere bygningerne i >>> >>> > > grupper, >>> >>> > > så hver .osm-fils bbox kun dækker et begrænset område og ikke nærmest >>> >>> > > hele kommunen, men det vil tage lidt tid at kode. >>> >>> > > >>> >>> > > - Generelt er det min holdning, at når bygningerne er mere præcise, >>> så >>> >>> > > er >>> >>> > > det muligt at gå ind i fx JOSM, søge efter overlappende bygninger >>> (via >>> >>> > > validatoren), fjerne alle fra kommunens datasæt og alle, der rent >>> >>> > > faktisk >>> >>> > > har tags på (ud over source og building=yes) og så slette de >>> >>> > > tilbageværende (dvs. de eksisterende bygninger i OSM, som ikke har >>> >>> > > nogen ekstra information lagt ind). >>> >>> > > >>> >>> > > - Og muligvis kunne det være fint med et godt bbox-opslag, der >>> trækker >>> >>> > > alle bygninger (points, ways og ikke mindst relations) ud som >>> grundlag. >>> >>> > > Dog, to bygninger i forskellige .osm-fil kan overlappe den samme >>> bygning >>> >>> > > i dette udtræk, hvilket kan føre til konflikt, hvis man vælger at >>> >>> > > slette en eksisterende bygning ved import af én fil, og senere vælger >>> >>> > > at slette samme bygning igen (ud fra det statiske udtræk) ved import >>> af >>> >>> > > en anden fil. >>> >>> > > >>> >>> > > Ellers nogen bud? Prøv eventuelt at hente én af .osm-filerne og tænk >>> >>> > > over, hvad der lige er at gøre. Det kunne være fantastisk at have >>> nået >>> >>> > > at importere alle bygninger til 1. januar, hvor kommunen gør brug af >>> en >>> >>> > > løsning over for borgerne, hvor de benytter OSM som baggrundslag. >>> >>> > > >>> >>> > > De rå filer fra kommunen er naturligvis også tilgængelige for >>> >>> > > interesserede: >>> >>> > > http://osm.ter.dk/data/frederikssund/ >>> >>> > > Min efterbehandling til .osm-filerne omfatter blandt andet at >>> indsætte >>> >>> > > de >>> >>> > > rigtige silo-tags på og få genereret korrekte multipolygoner for >>> >>> > > bygninger med "huller" i. >>> >>> > > >>> >>> > > - Peter Brodersen >>> >>> _______________________________________________ >>> Talk-dk mailing list >>> [email protected] >>> http://lists.openstreetmap.org/listinfo/talk-dk >>> >>> >> >
_______________________________________________ Talk-dk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-dk
