I was looking into the [new
Locators](https://osm2pgsql.org/doc/manual.html#locators) to see if we can
migrate some of our custom CSV based code to this new core feature.
I noticed that this would require us to rethink how we access the data compared
to what we do now.
It will likely be possible to do all we need, but different and maybe a bit
less performant…
So this is meant to share what we are planning to do and start the discussion
if it worth adding an additional feature to the locators.
**Our goal:**
For a given way, know if there is Mapillary coverage of type "panorama" or
"regular".
**Current approach:**
- We iterate over the bike lane segments in osm2pgsql
- We have an external dataset of areas that represent mapillary coverage
- https://github.com/vizsim/mapillary_coverage/tree/main/output
- Example
```csv
osm_id,mapillary_coverage
123,pano
234,regular
```
- We lookup the ID of the current osm object and add the external data als
"pseudo tags" to our ways properties to be used during other LUA processing
**This is the code ATM:**
https://github.com/search?q=repo%3AFixMyBerlin%2Ftilda-geo+mapillary_coverage+path%3A%2F%5Eprocessing%5C%2F%2F&type=code
Reading the CSV takes about 20 Min at the start of the osm2pgsql processing ATM.
```
processing | CSV: File cached (2.0s, 1537504 rows)
/data/pseudoTagsData/mapillaryCoverageData/mapillary_coverage.csv — Example:
{[1978] = {mapillary_coverage = "pano"}}
2025-10-06 09:35:44 Reading input files done in 1205s (20m 5s).
```
**How I would rebuild this using locators:**
- Instead of using the CSV, we pre process the polygons to merge all
overlapping, buffered Mapillary route lines into as few areas as possible.
These are either `pano` or (fallback) `regular` for the image type. However, we
can have overlapping areas, unless we substract the `pano` areas in a separate
step.
- I import that into a separate DB table
- I then create two locators, one for `mapillary_pano`, one for
`mapillary_regular`
- And then check against both to learn which it is.
Given the pre processing of the data, I can still use the `first_intersecting`
logic because we made sure beforehand that the pano area "win" for a given
area. I we skip the substraction step in the ata preparation we would have to
look at `all_intersecting` so see if one is `pano`.
**Alternative: Access properties of the area via the locator:**
I think the approach above should work but one has to think about the
properties as separate locators.
An alternative would be…
- We merge all areas (buffered mapillary routes) that overlap and give this
area a property "`coverage_type=pano|regular`"
- We then create one locator `mapillary_coverage`
- And when one OSM way as a `first_intersecting`, we access the `coverage_type`
property for that locator result
Since both approaches work in principle the difference will be mainly
performance and developer UX, I guess.
--
Reply to this email directly or view it on GitHub:
https://github.com/osm2pgsql-dev/osm2pgsql/discussions/2421
You are receiving this because you are subscribed to this thread.
Message ID: <osm2pgsql-dev/osm2pgsql/repo-discussions/[email protected]>_______________________________________________
Tile-serving mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tile-serving
