osm-fr / osmose-backend

Part of osmose that runs the analysis, and send the results to the frontend.
GNU General Public License v3.0
87 stars 109 forks source link

error: NULL location provided in osmosis_relation_public_transport for several norway* #1896

Closed Marc-marc-marc closed 11 months ago

Marc-marc-marc commented 1 year ago

https://buildbot.osmose.openstreetmap.fr/#/builders/639/builds/1002/steps/3/logs/stdio 2023-06-10 06:48:33 norway_aust_agder : osmosis_relation_public_transport 2023-06-10 06:48:33 osmosis resume post scripts 2023-06-10 06:48:35 run osmosis base analyser Analyser_Osmosis_Relation_Public_Transport 2023-06-10 06:48:35 requires table highways 2023-06-10 06:48:41 analyser_osmosis_relation_public_transport.py:616 sql 2023-06-10 06:48:41 analyser_osmosis_relation_public_transport.py:617 sql 2023-06-10 06:48:41 analyser_osmosis_relation_public_transport.py:618 xml generation 2023-06-10 06:48:41 analyser_osmosis_relation_public_transport.py:619 sql 2023-06-10 06:48:42 analyser_osmosis_relation_public_transport.py:620 sql 2023-06-10 06:48:42 analyser_osmosis_relation_public_transport.py:621 sql 2023-06-10 06:48:42 analyser_osmosis_relation_public_transport.py:622 xml generation 2023-06-10 06:48:42 analyser_osmosis_relation_public_transport.py:623 xml generation 2023-06-10 06:48:42 analyser_osmosis_relation_public_transport.py:624 xml generation 2023-06-10 06:48:42 analyser_osmosis_relation_public_transport.py:625 xml generation 2023-06-10 06:48:42 error: NULL location provided

frodrigo commented 1 year ago

Not a real error. The analyse emit an issue without location. Is logged, but not blocking error.

El sáb, 10 jun 2023, 10:01, Marc-marc-marc @.***> escribió:

https://buildbot.osmose.openstreetmap.fr/#/builders/639/builds/1002/steps/3/logs/stdio 2023-06-10 06:48:33 norway_aust_agder : osmosis_relation_public_transport 2023-06-10 06:48:33 osmosis resume post scripts 2023-06-10 06:48:35 run osmosis base analyser Analyser_Osmosis_Relation_Public_Transport 2023-06-10 06:48:35 requires table highways 2023-06-10 06:48:41 analyser_osmosis_relation_public_transport.py:616 sql 2023-06-10 06:48:41 analyser_osmosis_relation_public_transport.py:617 sql 2023-06-10 06:48:41 analyser_osmosis_relation_public_transport.py:618 xml generation 2023-06-10 06:48:41 analyser_osmosis_relation_public_transport.py:619 sql 2023-06-10 06:48:42 analyser_osmosis_relation_public_transport.py:620 sql 2023-06-10 06:48:42 analyser_osmosis_relation_public_transport.py:621 sql 2023-06-10 06:48:42 analyser_osmosis_relation_public_transport.py:622 xml generation 2023-06-10 06:48:42 analyser_osmosis_relation_public_transport.py:623 xml generation 2023-06-10 06:48:42 analyser_osmosis_relation_public_transport.py:624 xml generation 2023-06-10 06:48:42 analyser_osmosis_relation_public_transport.py:625 xml generation 2023-06-10 06:48:42 error: NULL location provided

— Reply to this email directly, view it on GitHub https://github.com/osm-fr/osmose-backend/issues/1896, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANT5DTEIMETPOULRBYX3S3XKQSWDANCNFSM6AAAAAAZBQZ56Y . You are receiving this because you are subscribed to this thread.Message ID: @.***>

Marc-marc-marc commented 1 year ago

Could the log level be changed to warning in this case? This complicates targeting real errors if non-errors have the error level log

frodrigo commented 1 year ago

We log it initially at error to improve the analysers. But now we can switch it warning.

El sáb, 10 jun 2023, 10:55, Marc-marc-marc @.***> escribió:

Could the log level be changed to warning in this case? This complicates targeting real errors if non-errors have the error level log

— Reply to this email directly, view it on GitHub https://github.com/osm-fr/osmose-backend/issues/1896#issuecomment-1585571138, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANT5DVNG7SS3VEPKRHPHKDXKQY6TANCNFSM6AAAAAAZBQZ56Y . You are receiving this because you commented.Message ID: @.***>

Famlam commented 1 year ago

https://github.com/osm-fr/osmose-backend/blob/3559f8519cad84d520b6d7399f0bf7de5b2fb9fa/analysers/Analyser_Osmosis.py#L637

Famlam commented 1 year ago

Hmm, it's a bit odd... Running it on netherlands_gelderland gives (among others) the following output of sql50:

variable output
parent.id 13990411
relation_members.member_id 13990410
ST_AsText(relation_locate(relations.id)) None
(+ 4 more outputs)

However, this relation is located in the UK, not in NL (Which explains why it can't find a location, since none of it's way/node members are in NL)

(Running it on Norway now...)

jocelynj commented 1 year ago

The diff process generation can keep some big relations (without their members) in diff. For example, the European-Union boundary is always kept. So I would recommend to check that relations contains a way/node in the pbf file (or in the database) before processing them.

But here, I'm not sure what the issue is, as the relation is very small - I will check the diff generation.

Famlam commented 1 year ago

But here, I'm not sure what the issue is, as the relation is very small - I will check the diff generation.

For norway_aust_agder (the extract from the first message) it's exactly the same relation that causes the error. The first 3 output arguments are: 13990411, 13990410 and None. So somehow that specific relation is (semi)global.

Marc-marc-marc commented 1 year ago

if a diff is only about the relation, without members in the diff, I suppose that the clipper is unable to detect the bbox of the relation and therefore put it in all extracts... if correct, that mean we have a lot of garbage in all extracts...

we could carry out a test by filtering the pbf and generating a diff between the current pbf and the filtered pbf, so that diff users (including osmose) have the information that thiis relation should not be part of this pbf at the next update. is it possible to improve the analysis log in order to have the relation number in the log? this would help corrections at the download.openstreetmap.fr level.

jocelynj commented 1 year ago

@Marc-marc-marc : the members of relation are taken from a world database, so we don't care about the polygon of the extract to detect if the relation is inside the extract or not.

I'm still trying to find how relation 13990411 was added to the netherlands_gelderland extract, but the zgrep commands are a bit slow on the server.

Famlam commented 1 year ago

I made a PR to address the first 4 comments (changing the error to a warning). However, I guess it's good to keep this issue open until the mystery of the UK bus line is solved

Famlam commented 11 months ago

Just out of curiosity, what was the cause of that relation being "everywhere"?