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

Add policy and definition of what should be included in the POI layer #40

Open
westnordost opened this issue Mar 8, 2024 · 1 comment
Labels

Comments

@westnordost
Copy link
Contributor

westnordost commented Mar 8, 2024

I believe there is an almost endless range of POIs that could be included in the POI layer.

If the shortbread schema is going to be used more, I predict lots of feature requests to add this or that POI to the list of POIs that should be present, plus of course discussions whether or not it satisfies any loosely or not loosely defined policy for inclusion. This will be hard.

So from the perspective of keeping the maintenance and also the possible points of contention low, the following solutions might be the best, though of course, they come each with obvious drawbacks:

  1. don't include POIs at all in the shortbread schema. This means no maintenance at all, but then, shortbread could not be a complete map as far as end user usage is concerned.

  2. policy-wise, only include POIs that are included in another OSM project, i.e. move the decision somewhere else. The most obvious would be the iD tagging schema and since it's maintenance is sponsored by OSMF, the current maintainer is very cautious to seek or wait for consensus on doubtful cases. JOSM presets or osm-carto (if it is then still maintained) would be options, too. All these options (except osm-carto) though do not solve the classification which map feature exactly should classify as a POI and which not. E.g. a traffic sign is certainly a map feature for which a preset exists or could exist, but it is not really a POI.

    We had a long discussion about this in StreetComplete. In the end, we settled towards having an overlay for "Places", roughly defined as "Map features like shops or amenities that usually have a name and can be entered" (=something you would enter into your car navigation). These are separate from "Things" shown in another overlay, like benches, bins, trees, lanterns, recycling, flagpoles. Anyway, policy-wise, we chose to write that places and things are only added to the list if they are already contained in the iD presets, to save us the prefiltering and discussion.

    EveryDoor, by the way, has a similar separation between places and things.

Do look at the links to the "Places" (and maybe "Things"), they contain many POIs I would consider should go into the POI overlay anyway. I just recently thoroughly researched this list via osm wiki and taginfo.

I could... create a feature request or PR for these, but I think it is important to settle on some form of inclusion policy and definition what exactly falls under a POI first.

@pnorman
Copy link
Contributor

pnorman commented Mar 8, 2024

I could... create a feature request or PR for these

Any PR is going to have to go against a separate set of files for version 1.1 of the schema. I don't think we're ready to create that yet, and I know I'd like to get the bugs fixed in 1.0 before copying it to start 1.1

@joto joto added the spec label Mar 13, 2024
pka pushed a commit to pka/shortbread-docs that referenced this issue Dec 2, 2024
…read-tiles#55)

* discussion shortbread-tiles#40

* discussion shortbread-tiles#46

* corrected Go code

* removed code block section

* changed heading to 'Inline Code Element'

---------

Co-authored-by: Saurabh Mishra <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants