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

Matches against unnamed stop positions #22

Open
lonvia opened this issue Nov 21, 2024 · 2 comments
Open

Matches against unnamed stop positions #22

lonvia opened this issue Nov 21, 2024 · 2 comments

Comments

@lonvia
Copy link

lonvia commented Nov 21, 2024

The final output has a MATCH between:

  • Delfi: "Wörth/Rh, Berufsschule", IFOPT: de:07334:32431:0:11
  • OSM: N 1697685732, "Wörth, Berufsschule"

While the match is right, the script keeps the wrong OSM object. It references to the unnamed public_transport=stop_position instead of the named highway=bus_stop (N336080300).

You'd want to prefer the highway=bus_stop (or railway=*) object as a general rule because Nominatim currently does not index public_transport=* objects at all (unless you changed the style).

@hbruch
Copy link
Member

hbruch commented Nov 21, 2024

Thanks for reporting this!

Usually, the matching prefers highway=bus_stops. It not completely ignores them, as there might be cases where no such bus_stop is in the vicinity (like e.g. for N9015403628 or N10246391038. Some of them seem to be out of service, but the DELFI zHV has no reliable way to identify these, as it's LastOperationDate is only available on parent stations not platforms and is deduced from (incomplete) time table data).

In the case of Wörth Berufsschule, de:07334:32431:0:11 reads in the zHV as it is not even a real stop or used for OnDemand transport without a well defined position :-/ :

"SeqNo";"Type";"DHID";"Parent";"Name";"Latitude";"Longitude";"MunicipalityCode";"Municipality";"DistrictCode";"District";"Description";"Authority";"DelfiName";"THID";"TariffProvider";"LastOperationDate";"SEV"
"43";"Q";"de:07334:32431:0:11";"de:07334:32431";"virtueller Haltepunkt 1 ohne Ortung";"49,051415";"8,247496";"00000000";"-";"-";"-";"";"NVBW";"-";"-";"-";"";"nein"

N336080300 is already matched to the higher ranked de:07334:32431:0:2.
grafik

Nominatim currently does not index public_transport=* objects at all (unless you changed the style).
That would result in stops mapped in PTv2-style only (public_transport=platform) would currently not show up? While that should be ok for rail-ish stops (they usually have a railway-key), some bus stops will not make it to Nominatim that way.

I think to remove matches between unnamed bus, ferry and funicular public_transport=stop_positions which are not highway=bus_stops at the same time and matched to zHV stops which currently have no route assigned:

select * from osm_stops o 
 join matches m on o.osm_id=m.osm_id
 join haltestellen_unified h ON m.ifopt_id = h.GlobaleId
 where o.match_state!='NO_MATCH' 
  and public_transport='stop_position' 
  and o.mode in ('ferry','bus','funicular')
  and (not highway='bus_stop' or highway is null)
  and linien is null
  and o.name is null;

Other matches usually indicate data issues in one source or another. They probably should not be imported into Nominatim, though I'd keep them for QA purposes.

@lonvia
Copy link
Author

lonvia commented Nov 21, 2024

So the match is not completely wrong. Delfi just has a platform more for this stop than OSM.

It might make more sense to look at this from the Delfi data perspective and remove the slightly odd platform types if there is a decent platform available for the same stop and it doesn't map at all or maps against a OSM stop_position (with or without name).

Nominatim currently does not index public_transport=* objects at all (unless you changed the style).
That would result in stops mapped in PTv2-style only (public_transport=platform) would currently not show up?

You should pretty much always find a highway=bus_stop in OSM on either platform or stop position because that is the only thing that shows up on the Carto map. I know there are exceptions but my experience is that we'd do more harm with getting lots of duplicates by also handling public_transport=* in Nominatim than by missing out on a few stops. In your case, the missing ones should get imported as external ones, so no harm done. Eventually, Nominatim needs a proper handling by merging platform and stop position.

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