search

tilezen / vector-datasource

Tilezen vector tile service - OpenStreetMap data in several formats
https://www.nextzen.org/
Other
507 stars 119 forks source link

Add new kinds for full OSM.org / iD icon library support #1425

Closed nvkelso closed 6 years ago

nvkelso commented 7 years ago

Around 39:

Dec. 12th: Looking at https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-points.mss, propose also:

pnorman commented 6 years ago

What should we do with objects which are shop=chemist amenity=pharmacy? amenity=pharmacy is already handled, this would add shop=chemist.

nvkelso commented 6 years ago

I would make sure shop=chemist is listed after amenity=pharmacy so kind=pharmacy would result from that combo (lower line number matches win).

On Thu, Nov 23, 2017 at 5:31 PM, Paul Norman notifications@github.com wrote:

What should we do with objects which are shop=chemist amenity=pharmacy? amenity=pharmacy is already handled, this would add shop=chemist.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tilezen/vector-datasource/issues/1425#issuecomment-346719014, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0EO75Ia-3fh9S-jBfldg7Ar5l1VhWrks5s5hxjgaJpZM4QQjEE .

pnorman commented 6 years ago

beach kind_detail beach_coarse from http://wiki.openstreetmap.org/wiki/Key:surface???

I'm looking at this and am not sure about it.

The osm.org reference to beach is https://github.com/openstreetmap/openstreetmap-website/blob/e3357b27e61c3ee4f4cf51c87fdc94deeaaa7c6f/config/locales/en.yml#L666 and iD has nothing about beach surfaces that I see.

Taginfo shows 19% of beach have surface, and 15% of beach have surface=sand. 1% have surface=pebblestone, and of the remaining 3%, they don't have a common enough tag to make taginfo.

nvkelso commented 6 years ago

This is from the OSM carto style, for the landuse polygons. We definitely need to include the ones that have polygon symbolizes. The others I care Less about. For now it can be a pass thru, with documenting the common values only.

On Dec 8, 2017, at 18:54, Paul Norman notifications@github.com wrote:

beach kind_detail beach_coarse from http://wiki.openstreetmap.org/wiki/Key:surface???

I'm looking at this and am not sure about it.

The osm.org reference to beach is https://github.com/openstreetmap/openstreetmap-website/blob/e3357b27e61c3ee4f4cf51c87fdc94deeaaa7c6f/config/locales/en.yml#L666 and iD has nothing about beach surfaces that I see.

Taginfo shows 19% of beach have surface, and 15% of beach have surface=sand. 1% have surface=pebblestone, and of the remaining 3%, they don't have a common enough tag to make taginfo.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

nvkelso commented 6 years ago

Looks like only OSM Carto beach_coarse is a symbolizer for the following surface values src:

 [natural = 'beach'],
    [natural = 'shoal'] {
      [surface = 'sand'] {
        polygon-pattern-file: url('symbols/beach.png');
        polygon-pattern-alignment: global;
      }
      [surface = 'gravel'],
      [surface = 'fine_gravel'],
      [surface = 'pebbles'],
      [surface = 'pebblestone'],
      [surface = 'shingle'],
      [surface = 'stones'],
      [surface = 'shells'] {
        polygon-pattern-file: url('symbols/beach_coarse.png');
        polygon-pattern-alignment: global;
      }
    }
pnorman commented 6 years ago

Looks like only OSM Carto beach_coarse is a symbolizer for the following surface values src:

SVG files have no direct relationship to OSM tags, e.g. square.svg is just a 1px square used multiple places where we wanted a square for a symbol. The tags go through osm2pgsql to turn into columns (generally a trivial transformation) then the SQL to MSS. In most cases it's easy to read off what the original tag is from the MSS selectors fairly easy, 95% are either [key = 'value'] or using a feature column and have [feature = 'key_value']. There are exceptions like like the [railway = 'runway'] which used to be used to select objects with aeroway=runway.

I'll go through and strike out the ones that are only file names, not related to OSM tags.

pnorman commented 6 years ago

For grave_yard_christian, grave_yard_generic, grave_yard_jewish, grave_yard_muslim kind_detail, I have a PR doing that right now, but I'm wondering if those are the best values for kind_detail. I think it would make more sense to have kind_detail of christian, jewish, or muslim, and no kind_detail for where it's not tagged.

This would also apply to kind_detail of forests with leaf_type and the wetland values.

nvkelso commented 6 years ago

I agree, just the religion value should go into kind_detail for graveyards.

On Dec 11, 2017, at 22:55, Paul Norman notifications@github.com wrote:

For grave_yard_christian, grave_yard_generic, grave_yard_jewish, grave_yard_muslim kind_detail, I have a PR doing that right now, but I'm wondering if those are the best values for kind_detail. I think it would make more sense to have kind_detail of christian, jewish, or muslim, and no kind_detail for where it's not tagged.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

pnorman commented 6 years ago

Do we really want to duplicate the religion between religion and kind_detail fields?

nvkelso commented 6 years ago

Yes. Religion should then be marked deprecated for 2.0 release.

Sent from my handsful device.

On Dec 14, 2017, at 11:43, Paul Norman notifications@github.com wrote:

Do we really want to duplicate the religion between religion and kind_detail fields?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

nvkelso commented 6 years ago

barrier=lift_gate is going into kind_detail (which is fine), but we'll need to add client logic for that. Same for barrier=swing_gate.

nvkelso commented 6 years ago

Filed some followup issues for the next milestone but generally everything here is verified (or has an issue). Closing :)