false positives on "oneway inaccessible"

[ComradeRamen]

Item:1210
Class:3
Multiple false positives on what I assume is the extract border.
Not sure if this is a separate issue from #1949

[Famlam]

Not limited to class 3 it seems, also class 1 has a suspicious warning on first sight at nearly the same position (might be a coincidence) :
https://osmose.openstreetmap.fr/en/issue/febf044f-bdc8-9713-ee8b-54ed840ec85a

The extract border is very very far away it seems (as far as I can see on my mobile phone) so I don't think that's related

Lets first see if we can reproduce it locally

[Famlam]

When I run this analyser on osm110 I only get one class=3 error for the entire of finland_north_savo, namely for this way (which seems correct).
The other class=3 items and the class=1 item for way 50261571 in that exact same region both only appear in the "online version" of Osmose, but not in osm110 with a freshly downloaded extract.

@jocelynj Could there be some data issue on the server? The ways involved don't seem to have been modified recently

• Osm110: 255x class 1 errors, and 1x class 3 error
• Osmose: 253x class 1 errors, and 5x class 3 errors
  (the lower count in the Osmose live version for class 1 may be related to border cutoffs)

./osmose_run.py --no-clean --extract-update-tool=osmium --import-tool=osmosis-parallel --skip-frontend --skip-frontend-check --skip-upload --analyser=osmosis_highway_deadend --country=finland_north_savo
Results file of osm110 at /data/work/famlam/results/Analyser_Osmosis_Highway_DeadEnd-finland_north_savo.xml.bz2

[ComradeRamen]

Another location at Idaho/Oregon border
And Nebraska/Colorado border
Another in Germany

[Famlam]

The finland_north_savo one reported in the first post seems different than the ones reported after this. (The one in Finland I cannot reproduce in osm110 and is also very far from any extract border)

---

However, I'm puzzled by the ones reported in this post. These ones (or at least the Idaho one) I can also reproduce on osm110.
In principle, the following piece of code (with {boundary_ids} = 162116 ) should find way 129088842 in the first JOIN, and then way 13905457 via the second JOIN, thus (effectively) whitelisting the nodes of way 13905457:
https://github.com/osm-fr/osmose-backend/blob/5543fee89da5925c95ef91bf41b81be2bda29027/analysers/analyser_osmosis_highway_deadend.py#L201-L213

However, it appears that the border crossing ways aren't even in table highways. If I run the following code on the extract of usa_idaho to select the border crossing way and the two ways after that (the latter are fully within Idaho):

SELECT
  id
FROM
  highways
WHERE
  id IN (13905457, 892510542, 39037116)

... the result is only [39037116]. However, all three ways (13905457, 892510542, 39037116) are fully or partially in Idaho and should thus exist in table highways of usa_idaho, not? (Only the frontend removes reports at the border, right? I thought on the backend it should include the full border + a margin outside of it? @frodrigo @jocelynj (not sure whom to cc for this) ).

If way 39037116 is the "first" one in table highways, then it makes sense that it is (incorrectly) detected by the analyser.

---

Same for the German case: way 279069706 even has two nodes in Sachsen, but is missing from table highways in the corresponding extract

[frodrigo]

I thought on the backend it should include the full border + a margin outside of it? @frodrigo @jocelynj (not sure whom to cc for this) ).

The extract loaded in database contains a margin. The analysers run on this data. Then the result issues are filtered on the backend while producing the report to be send to the frondend. It clips the issues on location marker using the exact border (if available on cache and/or valid from OSM data).

[Famlam]

Then I wonder why data inside the borders of the boundaries is missing from table highways.. I'll have a look at the raw extracts later, see if the ways are present there.

[Famlam]

The extract loaded in database contains a margin. The analysers run on this data. Then the result issues are filtered on the backend while producing the report to be send to the frondend. It clips the issues on location marker using the exact border (if available on cache and/or valid from OSM data).

So in that case think there's something going wrong with the extracts. See attached picture (I used germany_sachsen as example)

To make this picture:

1. I called osmconvert64-0.8.8p.exe germany_sachsen.osm.pbf -b=12.18,51.47,12.23,51.50 --drop-relations --drop-author --out-osm > sachsen.osm on the extract file of germany_sachsen
2. The boundary way was missing, so I added it in JOSM by downloading relation 62467 together with its members

p.s.: in the picture I wrote "should be extract border", I meant "would be extract border if there was zero margin".

[frodrigo]

germany_sachsen come from Geofabrik. The OSM extract polygon cliping is this one http://download.geofabrik.de/europe/germany/sachsen.poly

It cross multiple times the boundary.

We already see this for some extract from Geofabrik, and make report. But this issue will not be fixed on Geofabrik side. Thus extracts are not usable for Osmose.

cc @jocelynj

[ComradeRamen]

More at New York/New Jersey border after a recent valid edit

[ComradeRamen]

https://osmose.openstreetmap.fr/en/issues/false-positive?zoom=17&item=1210&level=1,2,3&limit=500&bbox=-73.95411417355969,40.85010027137602,-73.9496187912508,40.85427152902528

[frodrigo]

https://osmose.openstreetmap.fr/en/issue/8953e37b-ce5e-cca7-f8c6-fb410d8438df

https://osmose.openstreetmap.fr/en/map/#zoom=17&item=1210&level=1%2C2%2C3&limit=500&status=false&loc=21/40.8517078/-73.9524471

As it is inside the boundary, it should not be reported. Maybe a rounding error or a cached boundary polygon ?