Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Finland] Reviewing osmlint-osmium and osmlint data issues #409

Open
sbelemey opened this issue Apr 15, 2022 · 5 comments
Open

[Finland] Reviewing osmlint-osmium and osmlint data issues #409

sbelemey opened this issue Apr 15, 2022 · 5 comments

Comments

@sbelemey
Copy link

sbelemey commented Apr 15, 2022

Background

As part of on-going work to improve the quality of OpenStreetMap data, we use internal Mapbox data validation jobs that search OSM data for errors for detecting issues related to road network data in Finland. In total, we are going to review issues in 9 categories.

Our plan is to review all detected issues and fix it in OpenStreetMap. There's a link to the OSM Wiki page.

Timeframe

We are going to start review at the end of April 2022.

Tools

We will use existing OpenStreetMap editing tools, we will use #hashtag for the project #mapbox_linters_finland

Editor: iD
Satellite Imagery: MML Orthophoto, City of Turku ortophoto, Bing, Maxar, Esri
Street Level Imagery: Mapillary, OpenStreetCam, other open sources if available

Contact Person

We welcome feedback, suggestions, and insights from local mappers. If you have questions about this work, or a specific edit by our team, please reach out to Natallia ([email protected]). Also you can leave a comment in a changesets.

Linter Output for Finland

Here are json files by categories, you can watch them through geojson.io

Issue Data
Crossing Highways FI_crossinghighways.zip
Mixed Layer FI_mixedlayer.zip
Island Highways FI_islandhighways.zip
Impossible Angle FI_impossibleangles.zip
Impossible Oneway FI_impossibleoneways.zip
Missing Type Restriction FI_tr-missing_type_restriction_tr.zip
Missing Role FI_tr-missing_role_tr.zip
Excessive Roles FI_tr-excessive_role_tr.zip
Invalid Role FI_tr-invalid_role_tr.zip

cc @abrohood @shvrm @lukasmartinelli @vladaboitsik @sonyahilchik

@SomeoneElseOSM
Copy link

Hello,

Please answer (on this issue and every other country issue) the same questions that were asked at #387 , and make sure that a local mailing list also sees those answers.

Simply posting the same link without explanation for every country is not good enough.

-- Andy (SomeoneElse, from OSM's Data Working Group)

@sbelemey
Copy link
Author

Hi, @SomeoneElseOSM!
Our project documentation (wiki page and ticket) have an actual information. On our wiki page there're links on the pages with more detailed info about project, which contains categories and examples, and also page about how we deal with feedback. We seem through maining lists every day and promptly answers all the questions.
Here is the links on wiki pages (located on the main wiki page):
Mapbox linters types description
How Mapbox Data RAVE team work on receiving feedback from OSM users

best regards,
sbelemey

@SomeoneElseOSM
Copy link

Thanks - but that there are a couple of issues with that.

One is that communication isn't occurring - hence the angry reply at http://lists.openstreetmap.ch/pipermail/talk-ch/2022-April/011470.html ,

Another is that the quality of some of Mapbox's mapping doesn't reflect https://wiki.openstreetmap.org/wiki/How_Mapbox_Data_RAVE_team_work_on_receiving_feedback_from_OSM_users . The DWG have had a number of issues recently where Mapbox editors have changed something from "wrong, and detected by a QA metric" to "differently wrong, but not detected by a QA metric". In the long term editing like this harms the quality of OSM because it prevents mappers fixing problems properly.

Obviously we (the DWG) raise issues with individual mappers and if necessary with Mapbox directly but the worrying thing is that Mapbox as a company appears not to be learning from its mistakes - Mapbox has been involved with (and dependent on) OSM data for many years now but we're still seeing examples of really poor quality mapping, of the "just remove a tag so that a detected error goes away, never mind if it actually matches the actual situation" variety.

@sbelemey
Copy link
Author

@SomeoneElseOSM
Thanks for your feedback. We will discuss it within the company and give you an answer soon.

best regards,
sergey

@sbelemey
Copy link
Author

Hi, @SomeoneElseOSM!
thanks for your message! We sent a detailed answer to the mailing list.

best regards,
sergey

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants