add definitions for the structure of 31 relation presets#1538
add definitions for the structure of 31 relation presets#1538
Conversation
k-yle
added
waiting-for-schema-builder-change
waitfor-pr-merge
|
Ping #1591 for another candidate for this schema addition. |
|
also |
matkoniecz
added
waitfor-other
|
label changed per #1537 (comment) |
|
🍱 Your pull request preview is ready Please use this preview to check your changes. Ideally use the test documentation template and document your test results by commenting on the PR. This will speed up the review process for everyone. FYI, once this PR is merged, you can use the iD Editor Preview to test your changes in interaction with all other changes. |
| @@ -20,7 +20,7 @@ | |||
| "translations": "node scripts/translations.js" | |||
| }, | |||
| "devDependencies": { | |||
| "@ideditor/schema-builder": "~6.5.1", | |||
| "@ideditor/schema-builder": "github:k-yle/schema-builder#kyle-deploy", | |||
There was a problem hiding this comment.
this is temporary, to be changed on actual merge, right?
There was a problem hiding this comment.
yes, this is just to make testing possible - more details in ideditor/schema-builder#174 (comment)
| }, | ||
| { | ||
| "role": "stop_on_demand_exit_only", | ||
| "roleLabel": "Stop (Exit Only) (only stops on request)", |
There was a problem hiding this comment.
| "roleLabel": "Stop (Exit Only) (only stops on request)", | |
| "roleLabel": "Stop (Exit Only, only stops on request)", |
Though Inconsistent Capitalization Looks even worse now.
There was a problem hiding this comment.
| "roleLabel": "Stop (Exit Only) (only stops on request)", | |
| "roleLabel": "Exit only stop (stops on demand)", |
"on demand" should be equivalent to "on request"
There was a problem hiding this comment.
the problem with putting Exit only first, is that the list looks more chaotic.
To me, it seems a bit better when everything starts with Stop ...
There was a problem hiding this comment.
is this mockup? or is there way to test it in iD somehow?
There was a problem hiding this comment.
There's a lot of half-complete features in my fork of iD, which I will eventually make PRs for. Maybe I'll open some PRs tonight, but TLDR: no this can't be tested yet
There was a problem hiding this comment.
sounds like one more reason to process PRs you already opened :)
| "name": "Area", | ||
| "matchScore": 0.1 | ||
| "matchScore": 0.1, | ||
| "relation": { |
There was a problem hiding this comment.
it is mostly registering my confusion... But is this area entry representing both closed ways with area tags and multipolygons?
If yes, would adding this relations structure interfere with applying it to closed ways?
https://github.com/ideditor/schema-builder/pull/174/changes#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5 has For relations, so I guess nonrelations should ignore this structure?
There was a problem hiding this comment.
But is this
areaentry representing both closed ways with area tags and multipolygons?
yes, it's used by both
If yes, would adding this relations structure interfere with applying it to closed ways?
no, the code would just ignore this property for ways. Agree that it's a bit weird, but there's no other way to model it
| { | ||
| "role": "device", | ||
| "roleLabel": "Device", | ||
| "matchTags": [ |
There was a problem hiding this comment.
hmmmm
https://wiki.openstreetmap.org/wiki/Relation:enforcement gives example of red light camera placed on highway=traffic_signals without further tags
https://wiki.openstreetmap.org/wiki/Relation:enforcement#Example_5:_Distance_between_vehicles even wants to put it on tagless way
https://wiki.openstreetmap.org/wiki/Relation:enforcement#Example_7:_Height_check_before_tunnel also reccs tagsless device node
There was a problem hiding this comment.
https://www.openstreetmap.org/node/3524489413 is it valid?
What about https://www.openstreetmap.org/note/5192079 ?
There was a problem hiding this comment.
i have no idea. I guess we should trust the wiki and remove matchTags ?
There was a problem hiding this comment.
I guess it depends how this rules should be treated
- general claims about which relations are valid
- as guidance for editors
Because if it is guidance than being a bit prescriptive makes sense, but if violation of this rules should indicate invalidness of relation then they should be more relaxed and more matching what OSM Wiki permits and got used
| "role": "from", | ||
| "roleLabel": "From", | ||
| "geometry": [ | ||
| "vertex", |
There was a problem hiding this comment.
https://wiki.openstreetmap.org/wiki/Relation:destination_sign claims it may be also a node
(in such case can we express that line must be highway= but node may be tagless? )
There was a problem hiding this comment.
hmm, that's not really possible. I'll just remove matchTags
| "Climbing Cliff" | ||
| ], | ||
| "name": "Climbing Crag" | ||
| "name": "Climbing Crag", |
There was a problem hiding this comment.
is there anywhere documentation for it?
https://wiki.openstreetmap.org/w/index.php?title=Tag:climbing%3Dcrag has nothing
There was a problem hiding this comment.
it's documented on Climbing#Crags. I know nothing about this topic, I just added it because of #1538 (comment)
| } | ||
| ] | ||
| }, | ||
| { |
There was a problem hiding this comment.
wait, is entry of elements mattering?
if no, then it probably should
if yes, then maybe put it higher before this exotic stop variants to make editing easier?
This comment was marked as resolved.
This comment was marked as resolved.
| }, | ||
| "name": "Route" | ||
| "name": "Route", | ||
| "relation": { |
There was a problem hiding this comment.
type=route is also for hiking routes etc
maybe it would be better to put that definition into one of specific public transport routes and reference it from there
| "max": 1 | ||
| }, | ||
| { | ||
| "role": "subarea", |
There was a problem hiding this comment.
do we want to promote and support these?
IIRC these are fairly bad ideas but I may misremember
4 participants
Closes ideditor/schema-builder#134, Closes openstreetmap/iD#9127, Closes #1033
Lets discuss the schema structure at ideditor/schema-builder#174 and the keep this PR for bike-shedding the tagging and labels.
The CI will fail until ideditor/schema-builder#174 is merged & released.