Define schema - Githubissues

steveoh commented 2 years ago

We need to define the schema for trailheads.

[ ] #7
[ ] #8
[ ] #12

SGID trailhead schema

OBJECTID
PrimaryName
TrailheadID (managed by orbital, not useful to SGID)
Features (empty)
PrimaryMaintenance (empty)
SeasonalRestriction (empty)
InfoURL (empty)
Comments
DataSource

gregbunce commented 2 years ago

If we go the h3 route, the uniqueID field in both datasets could be called "h3-spatial-index" and we could add the level to the name once that's been determined.

steveoh commented 2 years ago

If we go the h3 route, the uniqueID field in both datasets could be called "h3-spatial-index" and we could add the level to the name once that's been determined.

My opinion is to follow the OSM convention of adding a UGRC id tag. Our discussion had too many issues with a spatial id I thought.

gregbunce commented 2 years ago

some notes from our meeting on 10/26/2022

use the osm schema plus add a sourceid tag on the osm side (consider getting this added to the official osm tag wiki)

for joinid: add joinid on the ugrc side (for data management and appending our internal fields - our fields are listed above). this can be a spatially assigned id. jake recommended we use hex_id + (underscore) 4th-6th decimals in lat + 4-6 decimals in long (ex: -111.123456 = 456)

eneemann commented 2 years ago

h3 resolution level 11 has 2149 sq m area, or is approximately a square with 46m sides
The OSM trails data only has 5 areas (10 trailheads) where trailheads are closer than about 70 m (see sorted distance matrix below)
h3 level 11 seems like a good scale to assign h3 indices

gregbunce commented 1 year ago

@eneemann (no rush on this)

are you able to provide us a summary of the osm trailhead tags that have been used? aka: what tags have folks used in the data that you downloaded from osm?

if it's easier, you could upload that dataset as geojson in github.

steveoh commented 1 year ago

the answer to that question @gregbunce and @eneemann might fit best in #7 or #8

eneemann commented 1 year ago

Here's a geojson of the existing OSM trailheads. There are a few dozen tags that have been used, but even the most popular ones only get like 5-10% usage (outside of the ID, name, highway=trailhead tags).

steveoh commented 1 year ago

colorado schema

https://trails.colorado.gov/

trailheads

name
manager
url
bathrooms
water
fee

trail

name
hiking
dogs
bikes
horses
motorcycles
atvs
ohvs
highway vehicles
surface
trail #
manager
url

This seems like a solid reference if nothing else.

gregbunce commented 1 year ago

proposed osm/sgid schema for trailheads (based on our 11/23/2022 meeting)

name
highway=trailhead
operator (who operates the trailhead. ex: usfs)
source (description of how/where the data was gathered)
drinking_water
toilets
shelter
bin (garbage bins)
website
fee (fee=no + fee:conditional=yes @ (stay > 2 hours) - parking with stay up to two hours free; fee=yes + fee:conditional=no @ (age < 12) - to mark something as free for children under the age of 12)
access
amenity

thoughts on JoinID (parked here for now) joinid on our internal data? is that still needed if we're not maintaining separate fields on our end?

eneemann commented 1 year ago

Just to have them documented, here are the tags used in the existing OSM Trailheads in Utah:

id
@id
amenity
highway
name
surface
type
@geometry
access
fee
operator
alt_name
place
barrier
bicycle
foot
ele
tourism
note
capacity
capacity:disabled
parking
source
addr:city
addr:postcode
addr:street
information
toilets
flickr
addr:housenumber

steveoh commented 1 year ago

Should we run this by our osm buddy? Martyen?

gregbunce commented 1 year ago

i feel like we should add the addresss tags to our schema.

addr:housenumber
addr:street
addr:city
addr:state
addr:postcode

thoughts?

ZachBeck commented 1 year ago

I think an address might be overkill. Does anyone here know the address of the Alexander Basin trailhead?

gregbunce commented 1 year ago

my thinking was for potential, future use cases such as emergency response, or navigation via addresses. it would need to be optional for sure.

folks would have to use a reverse geocoder such as atlas.utah.gov to populate the address.

but, yeah, your point is well taken.

maybe it is overkill.

eneemann commented 1 year ago

I was thinking it might be overkill, too. Only 1 trailhead in the OSM data currently has any of those attributes populated. And for 911 CAD data, I've usually thought of trailheads as something that wouldn't typically have an address. They're more of a 'point of interest' than a 'common place', which more relates to businesses and things with addresses in my CAD world. Plus, most addresses that we add would be made up from a reverse geocode, like @gregbunce notes, and wouldn't be a 'real' address.

gregbunce commented 1 year ago

good talk, good talk. i did notice we have an address point at the popperton park trailhead/parking lot.

i see what you're all saying, though. I'm processing it.

gregbunce commented 1 year ago

Okay I'm beginning to see clearer. Trailheads are probably better treated as commonplaces or landmarks and not addresses. You can still route to them.

gregbunce commented 1 year ago

proposed osm/sgid schema for trailheads (based on our 12/07/2022 meeting)

Required tags:

name
highway=trailhead

Optional tags:

operator (who operates the trailhead. ex: usfs)
drinking_water=yes/no
toilets=yes/no
bin=yes/no (garbage bins)
website (URL on where to go to get more info)
fee (fee=no + fee:conditional=yes @ (stay > 2 hours) - parking with stay up to two hours free; fee=yes + fee:conditional=no @ (age < 12) - to mark something as free for children under the age of 12)
access (use List of Possible Values)
source (wiki)

notes from the meeting:

if you use access=customers then fee=yes
we need to give examples and use cases for 'fee', 'source', and 'access'

gregbunce commented 1 year ago

any ideas on how we should make the proposed schema available for folks? I want to include that in the blogpost/videos.

gregbunce commented 1 year ago

do we want to try and propose it here: https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrailhead

we'd be requesting 7 additional tags,

gregbunce commented 1 year ago

@steveoh - i'm not as familiar with how the world of Wikis work, but my thought is to just dive in and edit that page. is that kosher?

gregbunce commented 1 year ago

okay, i've gone off the rails. i'm editing the wiki page.

gregbunce commented 1 year ago

the deed has been done. however, i didn't add the 'source' tag from our list b/c i couldn't quite wrap my head around what we're getting at. if someone else has a better grasp, please take a stab at it. also, i didn't want to push my luck with these new additions and that tag seems a little vague to me. https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrailhead

steveoh commented 1 year ago

It looks like this is the preferred method for adding tags

Document your custom tags

Main article: New Features When you use tags that aren't on map features, give other mappers a chance to understand (and maybe adopt) them by documenting them in the wiki. Please do not use the map features section of the wiki for this (including all wiki pages whose name starts with Key: or Tag:), as these are the community-endorsed tagging recommendations reserved for well-established tags with significant usage. Instead, you should set up a proposed feature page or put the documentation on your user page or a subpage of it. Or mention the tag on a "Discussion" section of a wiki page. Setting up a proposal is the preferred method of documenting custom tags.

And https://wiki.openstreetmap.org/wiki/Any_tags_you_like

Seems as though you were supposed to make a draft https://wiki.openstreetmap.org/wiki/Proposal

Update

I joined the osm slack and discussed gregs changes with some folks and their tone was very positive. The take aways are that these edits are too small to create a proposal for. It would bog down the system on little stuff like this. The wiki lacks specificity, so these edits are very welcome.

If we want to change the meaning of a tag, then a proposal is probably necessary.

steveoh commented 1 year ago

common existing tags for trailheads: https://taginfo.geofabrik.de/north-america/us/tags/highway=trailhead#combinations full list of us trailhead tags: https://gist.github.com/watmildon/dc851de535f1d7c259dfa1e181dc7bf7

gregbunce commented 1 year ago

it looks like our extended schema proposal will persist on the wiki, but with a few modifications from the main contributors of that page. I'm happy with it. https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrailhead

eneemann commented 1 year ago

Yeah, I think that's good!

steveoh commented 1 year ago

What changed specifically? From the edits I can't tell

gregbunce commented 1 year ago

Nothing content wise. They just moved our tags to a separate section/block on the page titled ‘additional tags’ or something like that.

On Sat, Mar 11, 2023 at 1:47 PM steveoh @.***> wrote:

What changed specifically? From the edits I can't tell

— Reply to this email directly, view it on GitHub https://github.com/agrc/collaborative-trailheads/issues/1#issuecomment-1465013830, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEA7QTDFMZLEEQTSGH77LS3W3TQG7ANCNFSM6AAAAAAQAUL2EY . You are receiving this because you were mentioned.Message ID: @.***>

-- Greg Bunce 801.349.0039

http://gis.utah.gov https://twitter.com/maputah

agrc / collaborative-trailheads

Define schema #1

SGID trailhead schema

colorado schema

trailheads

trail

Document your custom tags

Update