Details removed by import?

Communities Norge (Norway)
,
1

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
2

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 !

3

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

4

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.

5

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
6

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.

7

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
8

@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.

9

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.

10

@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.

11

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


12

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.

13

@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
14

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
15

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?

16

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
17

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.

18

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
19

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.