Single-Brand GeoJSONs?

[jdcarls2]

I've noticed for a few brands, like First State Bank (Michigan), they have their own geojson file. Granted, these banks may not actually serve the entire state that they're named for, I haven't checked. But could these simply be defaulted to their respective state geojson, now that those have been added?

Does performance improve if there are fewer geojsons overall? Or, if these brand-specific geojsons are more accurate for the given brand, is it preferable to simply leave them be?

[1ec5]

Some can be replaced with state GeoJSONs, but others are trickier. If I remember correctly, there are multiple People’s Banks (or something generic like that) headquartered in various states and serving different parts of Kentucky.

[jdcarls2]

Gotcha. I was thinking I might just open all the geojsons in a Q project to see what kind of stuff is in here.

[bhousel]

Yes, I'm sure many of the one we have can be replaced with the state ones to keep thing simple - I agree we should do this!
I did make a few more complex shapes for a few banks or transit companies that operate in overlapping regions.

• People's Banks: https://nsi.guide/index.html?t=brands&k=amenity&v=bank&tt=people
• The CATs of Portland: Refine locationSets for CATs #5252 (comment)

I also try to use the point-radius locationSets wherever possible too, because these are even simpler. ​

• For example MBTA extends beyond Massachusetts into neighboring states, so I just made that one a 100 km radius.

[jdcarls2]

@bhousel Ah, that was a related question I had, whether some of these could be downgraded to point-radius, especially where there's no real hard boundary to the service area.

[jdcarls2]

@bhousel Followup. Can a brand have two lon/lat/radius entries? Sun Tran (bus service in Tucson) has a single route that goes out to Ajo, and a circle big enough to catch that is going to clip into Phoenix a bit. Adding a second one just west of Tucson would cover it, though. But I don't know, it feels sort of hacky.

[bhousel]

Yes multiple point-radius includes is totally ok, I don't consider it hacky at all if it's a fair representation of the coverage area 👍

You can also use the https://location-conflation site to test these.
For fun I made a very bad approximation of New Jersey: { include: [[-74.5, 40.7, 90], [-75, 39.7, 90]] }

[bhousel]

Does performance improve if there are fewer geojsons overall? Or, if these brand-specific geojsons are more accurate for the given brand, is it preferable to simply leave them be?

This is a complicated question, but basically all of the locationSets get converted into GeoJSON and indexed when iD starts up. The simpler these GeoJSONs are (fewer points), the better.

I wouldn't worry too much about the complexity of the GeoJSONs because there is still a lot of performance that we can squeeze out of iD's location checking - a small code improvement here helped performance a bunch: openstreetmap/iD#8761

For example iD still does preset matching (which can cause a location lookup) on all its features when it renders them, instead it should just cache the matched preset.