Details removed by import?

Hi Norge!

I noticed that it looks like a lot of details that I spent hours surveying and adding along the E1 path in Femundsmarka have now disappeared (e.g. this stream Way: 1197165145 | OpenStreetMap). Looks like it was done as part of an import, @NKA I think you know something about this.

Obviously, it is not very satisfying to see hours of mapping going down the drain, but more importantly it seems like the situation left by the import process is less detailed (well mapped streams removed, width=* of streams stripped, streams smoothed to less accurate trace, …) than it was before. To some degree the outcome also appears directly inconsistent. For example the streams/paths no longer cross at the mapped bridges/fords like in this example: Way: ‪Linnes veg 1734‬ (‪1197165138‬) | OpenStreetMap. Maybe there some improvements to the import process should be considered? Maybe some cleanup/reverts of imports?

<rant>
I would argue that imports should never automatically remove/modify already mapped objects in the first place. I would also question the the value of duplicating freely available data (in this case “N50 topo”) at the cost of removing the unique data surveyed and added by contributors. But I guess that’s really up to the Norwegian community to decide for your part of OSM. After all, you have a lot of fjell to map… If policy is that imports override human mapping, I would suggest to somehow make that very clear to (foreign?) mappers, so that others don’t waste their time doing manual surveying/mapping in Norway only to have the work removed (I’ll admit I didn’t research the policy of the Norwegian community before mapping… Others might also not).
</rant>

God jul fra Danmark!

PS I write in English to spare you from Danish, but I understand Norwegian fairly well so feel free to respond like that

1 Like

Jeg antar at dette gjelder N50-importen i Engerdal kommune.

Jeg ser at noen få av dine sidebekker ikke har blitt med videre. Det kan tenktes at det har skjedd en glipp under importen. Alle gamle data er tatt vare på og jeg kan gå nøyere igjennom etter jul og se om noe bør legge tilbake.

Det aller meste av landdekke som fantes fra før i OSM i Engerdal var importert fra N50 tidligere, men hadde en del kvalitetsproblemer (bl.a. Visaman-import som har vært diskutert i community flere ganger). Det var også store mangler, bl.a. svært få bekker (tidligere 426 bekker mot nå 2539 bekker). Det nye landdekket er generelt og uten tvil mye mer detaljert og mer korrekt enn tidligere, f.eks. har innsjøer nå mange flere noder og har ikke gammel offset fra Bing.

Her er en oversikt over N50-importen: OSM-no-progress

Vi leser dansk greit her, siden det er vårt gamle skriftspråk :slight_smile:
God jul !

Jeg leser halvfjerds % dansk. Det er mest tallene jeg ikke skjønner.

Det er nok ein skrekk mange kartteiknarar har: at ein import skal koma å øydeleggja det arbeidet ein har gjort. Ville ikkje ha likt om ein nyimport hadde kome i ein av “mine” kommunar. :slight_smile:

Å overføra noko av det arbeidet kartverket gjer til OSM har nok framleis ein netto positiv verdi, men kjem med eit stadig aukande krav til aktsemd frå den som gjer importen. Dokumentasjonen på wikien går ikkje nok i djupna på korleis ein i praksis skal unngå tap av (verdifulle!) data.

Volumimport gjøres best før for mange har gjort jobb, men som fremgår av NKA sitt svar så var det heller ikke meninga at disse bekkene skulle forsvinne, så det er ikke så mye mer å si her :slight_smile:

1 Like

Ser at detaljer har forsvunnet også ved N50 importen i Enebakk kommune. For eksempel ble denne bekken slettet, Østre Morttjern fikk en mye grovere geometri, myra rundt tjernet forsvant helt, dette myrtjernet allerede importert fra N50, via Naturvernforbundet Oslo og Akershus i 2011, fikk 8 år med forbedringer tilbakestilt, og dette nye boligområdet ble slettet.
Jeg regner med at dette også var en glipp. Jeg vet hvor vanskelig det er å flette nye og eksisterende data ved en import. Men det er viktigere å ta vare på det vi allerede har som er bedre enn N50-dataene enn å bli ferdig med N50 importen.

Thanks for you response @NKA, hope you had a pleasant holiday!

This could be correct. I remember “N50” and “Engerdal” from som of the changesets that appeared to remove details.

From a visual evaluation it seems to me that all of the streams, wetlands, and forests that I had modified are replaced. But I don’t have a good way to estimate this systematically… Using the OSM web interface to walk through all modified ways of my months old changesets and check their current status is the only way I can think of, and I’m not going to do that… I would hope that you have better ideas/tools to verify imports?

That sounds right (and that is why I manually surveyed and improved OSM in this area when I was there anyway). The new import might well be a step forward from the old import, but surely a step backward from the work I (and many others across Norway?) had added.

I see that you have restored some objects (streams, water, other?) in Changeset: 145669509 | OpenStreetMap. My impression is that there is still restoration to be done. For example, the imported stream has been moved away from this bridge: Way: ‪Linnes veg 1734‬ (‪1197165138‬) | OpenStreetMap. Here is another bridge, edited by someone else 4 years ago, that now suffers from the same problem: Way: 759445187 | OpenStreetMap. Both bridges (and presumable the now removed streams) match the Kartverket terrain model and orthophotos well.

In general the detail level of the imported streams (and other objects?) appears fairly low, and in the areas I checked, streams I remember adding are still not back. I’m also fairly sure some wetlands I mapped are entirely missing. Probably forests too.

My only suggestion would be to roll back these imports entirely as soon as possible to avoid more entanglement with human input. There is no damage done in postponing the import! On the other hand, keeping the old imports will make it harder to untangle (and the imports appear to me to certainly have destroyed/suppressed high quality data).

If your goal with these imports is to improve on a previous low quality import, maybe the simplest would be to only touch objects that have not been modified since the old import? That would avoid replacing hand-mapped high quality objects with imported ones of (in my impression) lower quality.

Maybe someone with more experience with imports and mass edits has more refined ideas…

Venlig hilsen

EDIT:
Example of imported wood that has replaced the previous version that had more detail (both geometry and tag wise):
Old: Relation History: 16200417 | OpenStreetMap (found with overpass turbo)
New: Relation: 16687133 | OpenStreetMap

1 Like

@antonr: Jeg har gått igjennom alle 111 broer (og tilhørende bekker) i Engerdal og gjort noen få justeringer. I de fleste tilfellene var det broen som måtte flyttes litt (offset), ikke bekken.

For noen dager siden la jeg tilbake ca 100 bekker som du hadde tegnet. Dette var som tidligere nevnt en glipp under denne importen.

Jeg er ikke enig i det siste eksemplet ditt. Den nye skogen er en bedre representasjon av hva som “finnes på bakken” og har mye mer detaljerte kanter enn tidligere.

N50-importen som er gjort i det store flertallet av kommuner Norge og av mange brukere er basert på data tilpasset målestokken 1:50.000. Dette betyr at det er en relativt grov geometri, men likevel et godt utgangspunkt for videre detaljering fra enhver bruker. Du har nok ikke satt deg inn i disse importene når du nå foreslår å rulle dem tilbake. Skulle man gjøre det ville enorme mengder gode data gå tapt.

Markdekke i Engerdal generelt en meget stor oppgradering med denne importen og det er nå mye mer detaljer enn tidligere. Jeg håper nå at vi er ferdig med å diskutere dine redigeringer i Engerdal.

Har sett gjennom nokre av desse “nye” N50 importane no, og det ser ut for meg som dei tek lite omsyn til data folk kartlegger, med grov kartverksgeometri som overskriv alt. Mange stader går dette bra, sida det berre er gamle kartverksdata i områda, men det ser jo ikkje ut som dette faktisk blir sjekka (!)

N50-importen burde nok bli sett på vent til betre metodologi er på plass.

@sbre: Du gjør en del antagelser/gjettinger ovenfor om hvordan importene gjennomføres som blir helt feil. Det legges ned et stort og samvittighetsfullt arbeid, inklusive mye manuell tilpasning under forberedelsene, og alle større avvik mellom nytt og gammelt blir manuelt behandlet. Veldig mange feil i OSM blir korrigert manuelt. Der importer gjøres er N50 jevnt over mye mer detaljert enn kantete vann og skog som lå der fra før. Importer gjøres ikke i kommuner der det allerede er veldig mye detaljert manuell mapping.

Det er helt sikkert mulig å finne småtteri etter en import som kunne vært løst annerledes. Men husk at jobben må være gjennomførbar, med 10-50.000 ways per kommune, og hev gjerne blikket litt mot det større perspektivet, som er å få en brukbar representasjon av vann, skog og bebyggelse i OSM i Norge - også i områder der det ikke finnes mange aktive mappere. Uansett, om det var tvil: Kommentarene tidligere i tråden tas naturligvis til etterretning.

Vi er veldig nær å få topo ferdig i Norge, men erfaringen så langt viser at dette ikke skjer av seg selv, i hvert fall ikke i store usentrale kommuner. Det viktigste som gjenstår er 1) noen kommuner i Innlandet som fremdeles inneholder de gamle Visaman-importene (med veldig mange feil) og som ellers mangler mye topo, og 2) tre enormt store kommuner i Troms og Finnmark der mye er tomt. Alt dette vurderer jeg som uoverkommelig uten å gjøre importer.

I appreciate your effort. But I think this misses my main point: These imports could be destroying valuable manually added data across Norway. Engerdal is only interesting because I have very good and recent local knowledge, and thus can use this as a sample of the overall quality of these imports. My conclusions are still:

  • While this import may be better than the previous import, it is not better than mapping based on surveys and/or orthophotos and DEM.
  • The import process appears to indiscriminantly overwrite high quality mapping. Not only the previous low quality import.
  • It is appreciated that you try to correct mistakes as they are pointed out. But for large scale imports you cannot expect other people to catch mistakes. The import process must itself make sure existing data is not lost.

What about the (only) two concrete cases I mentioned? Here it was obvious to me that the imported streams were not aligned with neither orthophotos, DEM, nor hand mapped bridges. Did you move those bridges to match the imported data, and thus contradict the mentioned primary sources?

Maybe you could provide some concrete examples where you’ve moved bridges or where bridges and imported streams matched well already. That would make a factual discussion easier.

Surprised we disagree here!

I’m glad it seems we both have a goal of representing whats on the ground as best as possible. It seems somehow we have different opinions of how to best represent whats on the ground, or of how to evaluate this quality.

I base my estimation of the quality on having been to this particular “bakke” taking notes and photos as I walked there, as well as on the most recent orthophotos and terrain and surface lidar data (DTM/DOM) available in JOSM. As an example the very clear glades I observed and mapped appear to be missing in the imported forest. And obviously the tags detailing the type of wood has been deleted entirely.

What do you base your estimation of what matches reality on? Have you been to the place?

This much I understood already. I agree that 1:50k is a course scale. As far as I can see geometries are smoothed for ease of reading when rendered at that particular scale, thus not optimized for representational accuracy. My objection is that the import is NOT used as a starting point for refinement. On the contrary! It is used to replace already refined data!

No I have not. And I don’t think I need to in order to provide my input.

Good data is being lost by doing the imports! It seems fairly pointless to destroy the unique data of OSM, replacing it by a copy of less detailed data that is freely available elsewhere to anyone interested.

But ok, I checked the wikipage of the import. It says it represents consensus from a mailing list. Scrolling back in time on that mailing list, the most recent semirelevant post I found was one from May 2020 complaining that Import ødelegger… I don’t doubt that consensus was reached at some point, but maybe things have changes since then? At least in Denmark ~3 years of mapping changes a lot.

Look, I don’t dispute that the data of this import is better than the last bad import… As I mentioned in my first post, Norway is a big place, and imports may be fine as a starting point for further mapping (as you pointed out).

But please don’t delete other peoples high quality mapping, and replace it with data that is tweaked for rendering at 1:50k that is also freely available somewhere else.

This seems like a fairly silly thing to say… The topic of this thread is “Details removed by import?”. I don’t do imports… So, I’m not discussing my edits. I’m discussing detail-reducing imports in Engerdal (as a sample of all N50 imports). Or did I get the Norwegian possessive pronouns wrong? That would of course be embarrassing…

Vel, einaste kjelda eg har til korleis importane blir gjennomførde er det som er synleg endringssetta, samt det som står på wikisidene (som denne) om importen. Om det er meir viktig informasjon om korleis importen i praksis går føre seg, burde den dokumentasjonen vore der.

@antonr: Du har fått frem ditt budskap og jeg har forstått det. Vi er nok uenige om visse saker, men det er ikke nødvendig å krangle videre om detaljene (som var det jeg forsøke å si tidligere). Takk for å ha reist spørsmålet.

Jeg synes det nå er tid for at det norske community diskuterer hvordan N50-importen skal tas videre. Jeg håper noen av de som faktisk har gjort en N50-import og har erfaring med import-prosessen deltar i diskusjonen.

1 Like

Som en som har bidratt i N50-importer, tenkte jeg å dele noen perspektiver om denne diskusjonen.

De aller fleste steder i Norge er N50-dataene en forbedring over det som alt er der. Enten fordi det ikke er data der fra før, eller fordi det som er der er tegnet inn i en tid hvor man ikke hadde tilgang til like gode kildedata som i dag (ja, Bing, det er deg jeg tenker på). Derfor er det ønskelig å legge til rette for at N50-importen kan gjennomføres, så effektivt som mulig, uten at dette tar livsgleden fra de få personene som jobber med dette. Rent prinsipielt er jeg her enig med @NKA.

Det finnes også steder der data fra N50 vil utgjøre et betydelig tilbakesteg for datakvaliteten i OSM. Dette er som regel bidrag fra de siste årene med DTM og FKB-data tilgjengelig som støtte. Jeg er ikke i tvil om at @antonr sine overskrevne bidrag var et eksempel på en slik situasjon. Under mine egne importer har jeg selv også kommet over mange eksemplet på dette. I Lærdal hadde GustavGustavson sirlig tegnet inn store deler av Lærdalselvi for hånd etter FKB. :clap: Kan vanskelig se for meg hvor mye arbeid det må ha vært. Det ville vært uakseptabelt om importen min overskrev disse dataene.

Jeg har gjort importer i kommuner der det alt har vært gjort en del kartlegging fra før. Jeg har erfart at det er svært tidkrevende å manuelt sammenligne gamle og nye data. Dette utgjør ofte et hinder for å gjøre ferdig en import. Jeg har f.eks. prøvd å finne tid til å importere data for Ullvik i hele høst, uten å lykkes.

Spørsmålet er; kan man gjøre ta større hensyn til bevaring av håndtegnede data av høy kvalitet samtidig som man ikke tar gnisten fra importen? Jeg tror svaret er ja, men det kommer med en kostnad på andre områder, som må veies opp mot risiko for datatap. La meg skissere alternativet jeg har i tankene.

  • Jeg er ingen ekspert på merge-skriptet som brukes nå, men det aner meg at det kanskje er litt for ivrig til å erstatte eksisterende geometri. Dette kan man antakelig enkelt gjøre noe med ved hjelp av å introdusere diverse sjekker. F.eks. om den eldre geometrien har større punkt-tetthet enn den nye bør man være forsiktig. Se @Noen sin kommentar med eksempler.
  • Mindre automatisk fletting betyr også mer manuell sjekking. For å unngå at dette blokkerer en import kan et alternativ være at vi utsetter flettingen av alt som må sjekkes manuelt til etter importen. Dette har jeg selv gjort i f.eks. Sør-Varanger. Der gjorde jeg importen først og tok meg så god tid over de neste ukene til å flette.
  • Ulempen med dette er at man må leve med en mer rotete database i kortere eller lengre tid, avhengig av hvor motivert den som importerer er for å ferdiggjøre flettingen. Dette betyr overlappende landcover, landuse og waterways. Man mister også historie når man sletter noe gammelt til fordel for noe nytt, heller enn å bare bytte ut geometrien.

Hva tenker folk om dette forslaget? Er prisen verdt å betale?

2 Likes

Om ein kan (til slut) nå eit betre resultat på denne måten, er det noko eg kan seia meg nøgd med. Kan godt flette-rydda ein tilvist del av Finnmark om det er som skal til.

Teknisk, kva er i vegen med verkty som JOSM “replace geometry” når ein jobbar på denne måten? Går historie framleis tapt?

Replace geometry er ikke laget for slike avanserte erstatninger virker det som.

Helt konkret replace-geometry på en myr fra N50 vs en håndtegnet mye så er det kanskje ikke like mange elementer i myren. Så du erstatter den gamle myren (som kanskje bare er en way) med mange nye biter. Da er det kun 1 av de nye myrbitene som har historikken til den gamle.

Og hvis det er noe som helst som kompliserer det du ønsker å erstatte (det er noder på ene wayen, den tilhørere en relasjon etc) så blir det bare masse ekstraarbeid.

1 Like

Det ville nok gått raskere om man delte på ansvaret for opprydningen, ja.

Replace geometry fungerer ikke når begge objektene ligger i databasen. Ett av objektene må være nytt. Så da må man evt. kopiere N50-objektet, slette det, lime det inn igjen, og så bruke replace geometry. Litt tungvindt, men for så vidt gjørbart om man vet hvordan.

Bra innspill her nå. Noen tanker:

  • Innspillet fra Anton om broer og vadesteder (ford) er en god ide. Vegimporten er nok for det meste gjort uten å se på bekkene, så en sjekk for disse kan gjøres.

  • Toleransegrensene i skriptet kan justeres. Har gjort dette flere ganger, avhengig av mye/lite offset.

  • Synes nok at flettingen bør skje under importen, ellers mister man historien, som harahu nevner. Det er respektfullt overfor forrige bruker å beholde historikken der det er mulig. Også fare for at duplikater bare blir glemt i OSM.

  • Fortsette å ta vare på elementer med høy kvalitet. Elveløp er godt eksempel. Litt vanskeligere for elementer med litt vag avgrensning som er vanskelig å verifisere via ortofoto (skog, myrer osv).

  • God ide å la flere mappere bidra til litt etterarbeid/finpuss. Selve importen er dessverre en tidkrevende drittjobb, så lite håp om å få mange til å delta der.

  • Kommuner med mye manuell, detaljert mapping vil nok aldri bli importert, så det løser seg selv.

1 Like

Jeg vet at koden er tilgjengelig, og kan leses. Har du likevel lyst å si litt om hvilke kriterier (uavhengig av toleransegrense) som brukes for å vurdere om f.eks. waterways skal erstattes med noe fra importen eller ei?

Tenker at det kan være greit å få litt diskusjon rundt hva som er akseptable kriterier for folk, og kanskje idémyldring rundt hva vi potensielt kan gjøre annerledes/bedre.

Jeg kommuniserte det ikke tydelig nok, men jeg syns også det er best at så mye som mulig fletting skjer under importen. Erfaringen min er at de fleste konfliktene i antall er relativt lette å flette, men at det finnes en “long tail” med vanskelige tilfeller, der det gjerne er vanskelig og tidkrevende å vurdere hva som skal beholdes, og hva som bør være arvtaker-geometrien. Det er vel gjerne disse jeg tenker burde kunne spares til etter importen og evt. crowdsources, da det er disse som bidrar mest til å gjøre importen tidkrevende. Men det har uansett en kostnad, ja.

Det kommer helt an på prosedyrene man bruker. Om det finnes en prosedyre for post-import merging, med validering og tracking tror jeg dette blir et mindre problem en man kunne frykte. Men ja, det er en risiko.

Jeg vil ikke ta vare på alle gamle elveløp heller. Eksempelet mitt fra Lærdal kan også være et unntakstilfelle for alt jeg vet. Poenget er vel at vi trenger noen brukbare heuristikker for når vi mener det er greit å erstatte noe automatisk, og når det ikke er det. Jeg tenker f.eks. at det meste som stammer fra Bing-æraen må være greit å bytte ut, pga. offset. Om punkt-tettheten er betydelig lavere enn i importmaterialet burde det gjerne også være greit. Om de gamle dataene stammer fra en tidligere import er det heller ikke noe problem. Men ut over det begynner vi å komme inn i en gråsone hvor det kan være fint å diskutere hvor grensene bør gå. Håper vi kan få til en samtale ift. det.