Closed tas50 closed 3 years ago
Perhaps common terms like "Metro" should have a filter that won't suggest it unless it has a non-country-code locationSet - such as only when there is a .geojson or a radius locationSet?
I am also wondering, is there any possibility of adding to the yellow box area in iD, and including a link to "report incorrect suggestion" so users who see an NSI suggestion they know is incorrect can flag it, or be linked to this repository?
@bhousel
We need to sprinkle some locations on these. Metro is way too common a name so the suggestions coming from iD aren't the best right now.
I agree! I think all of the transit and many of the operator items could benefit from a smaller locationSet
than country-wide.
My workflow for adding these is still kind of cumbersome, so I might look for ways to improve it.
Figure out where the thing is actually used. I check with Overpass or just look at the official transit map. We have network=Metro
all over the place:
[out:json][timeout:100];
(nwr["network"="Metro"];);
out body;
>;
out skel qt;
Go to geojson.io and make a point where you want the center to be:
{
"type": "FeatureCollection",
"features": [
{
"type":"Feature",
"properties":{},
"geometry":{
"type":"Point",
"coordinates":[
-95.37094116210938,
29.76795366711911
]
}
}
]
}
Go to the location-conflation viewer page and paste that in, trim the excess precision, and adjust the center and radius manually until it looks right:
{ include: [[-95.37094,29.76795,150]] }
Then you have a locationSet
that can be used in NSI.
So, I'm thinking it would be great to add some simple drawing tools to that location-conflation page, so I dont need to manually adjust the size and position.
Perhaps common terms like "Metro" should have a filter that won't suggest it unless it has a non-country-code locationSet - such as only when there is a .geojson or a radius locationSet?
Yes for a really common name like "Metro" if we decide it is too much work to make narrowly scoped items for all of them, we could add it to the "named" exclude list here, then it wouldn't trigger the upgrade suggestion:
"properties": {
"path": "transit/route/subway",
"exclude": {
"generic": ["^subway$"],
"named": [
"^(city|international|local|mtb|municipal|national|rail|regional|urban)$"
]
}
},
I am also wondering, is there any possibility of adding to the yellow box area in iD, and including a link to "report incorrect suggestion" so users who see an NSI suggestion they know is incorrect can flag it, or be linked to this repository?
What I'd really like to do here is:
not:network:wikidata=Qxxx
tag so that the suggestion doesn't appear again.not:*:wikidata
tags is signal that NSI might be missing something!I agree we could add a link or something to encourage users to report incorrect suggestions.
I will note that I added detailed tags for LA Metro's various bus networks in #5164, so hopefully that will help resolve this specific case. Though obviously that doesn't solve the root issue of ambiguous names. Not sure how long it takes to propagate to OSM/iD, or if it will successfully find the correct networks over other "Metro"-containing options.
Not sure how long it takes to propagate to OSM/iD.
Now that NSI V6 is part of iD, any changes we make here will appear quite quickly, likely within a few days, as once a new release is published on our side (something @bhousel does quite often) it will instantly be available within iD.
I'm going to close this for now since the original issue with the different "Metros" should be fixed and I've added a LOT of more specific locations to the transit items. We'll continue to do this and that will make the suggestions even better.
I've also written some code to allow users to tag a suggestion as not:
the thing being suggested, so that should help these ambiguous cases too: https://github.com/openstreetmap/iD/pull/8628
We need to sprinkle some locations on these. Metro is way too common a name so the suggestions coming from iD aren't the best right now.