You are not logged in.

#26 2020-01-26 00:43:28

farad
Member
Registered: 2015-08-27
Posts: 4

Re: Forest import

What is the current state about this? I have run into a lot of erroneous forests created by this import in my new neighborhood in Oulu and started cleaning them up, which requires a lot of fiddling around with multipolygons.

But after thinking about it again, I was wondering whether manual fixing is the right way here. Should I just leave these - although they interfere with other edits - so that they can be cleaned up automatically?

Terveisin
Farad

Last edited by farad (2020-01-26 00:45:04)

Offline

#27 2020-01-26 18:13:01

posiki
Member
Registered: 2010-03-26
Posts: 227
Website

Re: Forest import

farad wrote:

What is the current state about this? I have run into a lot of erroneous forests created by this import in my new neighborhood in Oulu and started cleaning them up, which requires a lot of fiddling around with multipolygons.

I need to prepare custom scripts to make reverts: existing tools will leave some features to database.

farad wrote:

But after thinking about it again, I was wondering whether manual fixing is the right way here. Should I just leave these - although they interfere with other edits - so that they can be cleaned up automatically?

My plan is that those custom revert script won't touch if somebody have been updated features. So, if you clean or modify those forest plots, I won't revert (aka delete) those.

P

Offline

#28 2020-04-28 11:43:08

Hadena
Member
Registered: 2018-09-08
Posts: 11

Re: Forest import

What is the update on this?

Offline

#29 2020-05-04 16:15:18

posiki
Member
Registered: 2010-03-26
Posts: 227
Website

Re: Forest import

Hi!

Hadena wrote:

What is the update on this?

I have prepared Python scrit for reverting and tested it. If you like help me for testing (and further develop the script), I can share it. Or I can put into github repo or something.

P

Offline

#30 2020-10-17 11:54:26

farad
Member
Registered: 2015-08-27
Posts: 4

Re: Forest import

github repo would be great, since then the algorithm itself could be discussed

farad

Offline

#31 2020-10-22 13:43:57

smartsmartie
Member
Registered: 2020-10-22
Posts: 1

Re: Forest import

Hi! smile

I'm quite new at OSM and have read about this import yesterday. And I'd like to quickly point out a way how to use the data in a way which might be appreciated by the community. Sadly, I won't have time to do this myself, so this is just supposed to be a quick idea for anyone interested.

Firstly, I agree that this whole import needs to be reverted because what you did, posiki, is overfitting of your data (https://en.wikipedia.org/wiki/Overfitting).

But in my opinion, such a large amount of data is a huge chance to improve OSM if it is used in the right way. Such an import should not cause any harmful interference with past or future edits of the community. After reverting the first import, you could follow these steps:

1. Vectorization of the pixel forest data: Initial forest patches just as you did, posiki.

2. Creation of new forest patches, only based on new points at the center of each line of the initial forest patches. Like this, you effectively average each two neighboring points. This eliminates most of the pixel structure without increasig the amount of points. And you avoid overfitting: You use a minimum amount of points to represent the forest shape at the accuracy of the underlying data set. This sows the accuracy of the data to future mappers and makes future improvements as easy as possible because they need to move only a few points for corrections.

3. Only cut out highways of type tertiary and above. Like this, you avoid pseudo mapping of small roads and paths with small blank lines in the forest as you did before. Thus, future mappers won't run into accidentally merging your forest points with their new highway points.

4. Cut out all existing OSM areas except of forest with 3m buffer (buildings, landuse, lakes, sportsgrounds etc.). Cut out forest without buffer. Like this, you avoid sharing points with any existing OSM object except of forest. Thus, future mappers can change these without being bothered by freeing them from your forest.

5. Deletion of all forest patches below 2300m². The LUKE data set's pixels are sized 16m x 16m. So you should at least delete all patches below an area of 3x3 pixels, 48m x 48m, approx. 2300m² to avoid messy small forest patches.

6. Test import and visual inspection at randomly chosen areas.

7. Community Discussion. Adding additional image processing steps if needed.

8. Full import.

In my opinion, OSM needs to welcome and professionaly process external data to keep up with e.g. AI based map services in the future. That's why I want to thank you, posiki, for caring about importing this data. I hope I could help a little with this.

Cheers,
smartsmartie

Offline

Board footer

Powered by FluxBB