Re: [Talk-us] Per-State relations for the Appalachian Trail
On 05/03/2016 03:09 PM, OSM Volunteer stevea wrote: In the USA, partly because we are such a geographically large part of the North American continent and partly because each of our fifty states is sovereign, I find that breaking apart very large relations so they are across a single state at a time (then perhaps these are collected into a super-relation) is often (though not always) a sensible approach. It is part size (large relations with vast numbers of members are unwieldy), it is part “what sort of an entity is this politically?" For example, there is a note in OSM’s Amtrak wiki page on the route=train relation for the California Zephyr: "The relation is said to be so big it is hard to work with.” That is something we might take to heart and break apart the relation into statewide components. I haven’t done that, but somebody might, after considering that it makes editing easier, and that state-at-a-time is a good way to do this. Even a simple web browser request to display this relation results in "Sorry, the data for the relation with the id 905830, took too long to retrieve." The practicality of potentially better avoiding edit conflicts has been mentioned, and is also true. Breaking apart the AT into separate relations - ideally with a superrelation joining them - would be sensible, I think, but be careful about the assumption about state lines. The AT literally spends a good many miles with the hiker having one foot in North Carolina and the other in Tennessee - the ridge that it follows is the state line. We also, I think, need to put some more thought simply into the support of large relations. I've recently found that even the New York Long Path (only a fifth the length of the AT) crashes JOSM (I haven't yet diagnosed the problem) and wound up editing in Meerkartor instead. Trails, highways, rivers, railroads, we have a good many places where things reasonably and predictably break down into thousands of parts over thousands of km, and I don't think we yet have a unified theory of how to handle them. -- 73 de ke9tv/2, Kevin ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Whole-US Garmin Map update - 2016-04-30
These are based off of Lambertus's work here: http://garmin.openstreetmap.nl If you have questions or comments about these maps, please feel free to ask. However, please do not send me private mail. The odds are, someone else will have the same questions, and by asking on the talk-us@ list, others can benefit. Downloads: http://daveh.dev.openstreetmap.org/garmin/Lambertus/2016-04-30 Map to visualize what each file contains: http://daveh.dev.openstreetmap.org/garmin/Lambertus/2016-04-30/kml/kml.html FAQ Why did you do this? I wrote scripts to joined them myself to lessen the impact of doing a large join on Lambertus's server. I've also cut them in large longitude swaths that should fit conveniently on removable media. http://daveh.dev.openstreetmap.org/garmin/Lambertus/2016-04-30 Can or should I seed the torrents? Yes!! If you use the .torrent files, please seed. That web server is in the UK, and it helps to have some peers on this side of the Atlantic. Why is my map missing small rectangular areas? There have been some missing tiles from Lambertus's map (the red rectangles), I don't see any at the moment, so you may want to update if you had issues with the last set. Why can I not copy the large files to my new SD card? If you buy a new card (especially SDHC), some are FAT16 from the factory. I had to reformat it to let me create a >2GB file. Does your map cover Mexico/Canada? Yes!! I have, for the purposes of this map, annexed Ontario in to the USA. Some areas of North America that are close to the US also just happen to get pulled in to these maps. This might not happen forever, and if you would like your non-US area to get included, let me know. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Per-State relations for the Appalachian Trail
In the USA, partly because we are such a geographically large part of the North American continent and partly because each of our fifty states is sovereign, I find that breaking apart very large relations so they are across a single state at a time (then perhaps these are collected into a super-relation) is often (though not always) a sensible approach. It is part size (large relations with vast numbers of members are unwieldy), it is part “what sort of an entity is this politically?" For example, there is a note in OSM’s Amtrak wiki page on the route=train relation for the California Zephyr: "The relation is said to be so big it is hard to work with.” That is something we might take to heart and break apart the relation into statewide components. I haven’t done that, but somebody might, after considering that it makes editing easier, and that state-at-a-time is a good way to do this. Even a simple web browser request to display this relation results in "Sorry, the data for the relation with the id 905830, took too long to retrieve." The practicality of potentially better avoiding edit conflicts has been mentioned, and is also true. The number of elements in this Zephyr relation is over 2500, and that can make editing and display difficult. When OSM bumps up against real limits of practicality like this, we should pay attention by discussing strategies like subdividing using sensible approaches and methodologies. It may not always be obvious when to break apart a large relation into statewide components, but neither should it surprise us when somebody (for reasons of logical subdivision, practicality or both) does so. SteveA California___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Improving coverage of exit numbers and destinations on motorways
Hey all, I believe the way-junction:ref should be used in addition to the node-ref only when needed at splits - like this example: http://wiki.openstreetmap.org/wiki/Exit_Info#A.2FB_Split_Example These types of splits do not happen very often - however, when they do - having the way-junction:ref helps to improve the guidance for the user at key decision points. Regards, Duane On Tue, May 3, 2016 at 10:02 AM, Jinal Foflia wrote: > Hi Paul, > > These are good points, but it does not look like the `junction:ref` > tagging scheme is very common. Till there is widespread usage by the > community we will continue to follow the conventional tagging of the > reference numbers on the motorway_junction node [1]. > > Curious to know what the others think of the `junction:ref` tag. > > Cheers, > Jinal Foflia > > > [1] http://taginfo.openstreetmap.org/search?q=highway%3Dmotorway_junction > > > On Tue, May 3, 2016 at 3:49 PM, Paul Johnson wrote: > >> I'm wondering why the push to tag a node with directional information >> when tagging the first segment of the diverging way would be more concise >> and already had support in some navigational data consumers? This handles >> weird situations where ramps diverge to the left or from a lane other than >> the edge much more cleanly. >> >> For example, Exit 2 in West Tulsa on I 244. First segment could be tagged >> as... >> >> name=Okmulgee Beeline >> junction:ref=2 >> destination=Okmulgee >> destination:ref=US 75 South >> ref=US 75 >> highway=motorway >> >> Or, the number 3 lane exit westbound US 26 north of Beaverton at exit 71A >> (lanes 1, 2 and 4 remain on US 26, oddly enough). >> >> name=Canyon Road >> highway=motorway_link >> ref=OR 8 >> junction:ref=71A >> destination=Beaverton >> destination:ref=OR 8 West >> >> This along with the departure angle, gives navigation systems ample >> information to accurately describe the ramp that point data just leaves out. >> >> >> On Tue, May 3, 2016 at 4:46 AM, Jinal Foflia >> wrote: >> >>> There has been a recent push to improve the coverage of exit numbers and >>> destination signs on the motorways in the US by the data team at Mapbox. >>> Some context here [1][2][3][4]. The primary sources of data were DoT >>> documents and Mapillary images. The secondary source was Wikipedia, but as >>> per the conversation with the local mappers, it is not a good idea to >>> completely trust wikipedia documents for mapping the exit numbers and >>> destinations. There are certain highways which do not have Mapillary >>> coverage and it is difficult to validate/identify the missing exit numbers >>> and destination. It will be a great help if local mappers can help share >>> reliable sources and validate the existing data that will help improve the >>> coverage of this data on the map >>> >>> We been working on this from the beginning of April and reviewed more >>> than 220 highways in 9 states. The goal would be to authenticate all >>> the existing data and fill in the gaps using verifiable sources wherever >>> possible. >>> >>> Here is the Overpass query to get a better sense of the stats: >>> >>> * Total motorway_junction edited by team in last two weeks: 179 [5] >>> >>> This is the detailed workflow for *Exit mapping* [6] and *Destination >>> mapping* [7] that was used for this mapping activity. Would be great to >>> hear your feedback on how it can be improved for further such tasks, please >>> drop a comment on the *project tracker* [3] . >>> >>> I want to thank all of you in the community for giving feedback, calling >>> us out on the occasional errors, and working with us to improve signpost >>> mapping conventions. I feel proud to be a member of such a great mapping >>> community! >>> Cheers, >>> >>> Jinal Foflia >>> >>> [1] https://www.openstreetmap.org/user/jinalfoflia/diary/38501 >>> >>> [2] https://www.openstreetmap.org/user/jinalfoflia/diary/38342 >>> >>> [3] https://github.com/mapbox/mapping/issues/178 >>> >>> [4] https://github.com/mapbox/mapping/issues/169 >>> >>> [5] http://overpass-turbo.eu/s/fzA >>> >>> [6] >>> https://gist.github.com/poornibadrinath/a8f3652deb566d95b848c5e9cd68011f >>> >>> [7] >>> https://gist.github.com/poornibadrinath/f982a947c6a063ed1a9016a2d3246d4a >>> >>> >>> >>> >>> ___ >>> Talk-us mailing list >>> Talk-us@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-us >>> >>> >> >> ___ >> Talk-us mailing list >> Talk-us@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-us >> >> > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us > > ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Improving coverage of exit numbers and destinations on motorways
Hi Paul, These are good points, but it does not look like the `junction:ref` tagging scheme is very common. Till there is widespread usage by the community we will continue to follow the conventional tagging of the reference numbers on the motorway_junction node [1]. Curious to know what the others think of the `junction:ref` tag. Cheers, Jinal Foflia [1] http://taginfo.openstreetmap.org/search?q=highway%3Dmotorway_junction On Tue, May 3, 2016 at 3:49 PM, Paul Johnson wrote: > I'm wondering why the push to tag a node with directional information when > tagging the first segment of the diverging way would be more concise and > already had support in some navigational data consumers? This handles > weird situations where ramps diverge to the left or from a lane other than > the edge much more cleanly. > > For example, Exit 2 in West Tulsa on I 244. First segment could be tagged > as... > > name=Okmulgee Beeline > junction:ref=2 > destination=Okmulgee > destination:ref=US 75 South > ref=US 75 > highway=motorway > > Or, the number 3 lane exit westbound US 26 north of Beaverton at exit 71A > (lanes 1, 2 and 4 remain on US 26, oddly enough). > > name=Canyon Road > highway=motorway_link > ref=OR 8 > junction:ref=71A > destination=Beaverton > destination:ref=OR 8 West > > This along with the departure angle, gives navigation systems ample > information to accurately describe the ramp that point data just leaves out. > > > On Tue, May 3, 2016 at 4:46 AM, Jinal Foflia > wrote: > >> There has been a recent push to improve the coverage of exit numbers and >> destination signs on the motorways in the US by the data team at Mapbox. >> Some context here [1][2][3][4]. The primary sources of data were DoT >> documents and Mapillary images. The secondary source was Wikipedia, but as >> per the conversation with the local mappers, it is not a good idea to >> completely trust wikipedia documents for mapping the exit numbers and >> destinations. There are certain highways which do not have Mapillary >> coverage and it is difficult to validate/identify the missing exit numbers >> and destination. It will be a great help if local mappers can help share >> reliable sources and validate the existing data that will help improve the >> coverage of this data on the map >> >> We been working on this from the beginning of April and reviewed more >> than 220 highways in 9 states. The goal would be to authenticate all the >> existing data and fill in the gaps using verifiable sources wherever >> possible. >> >> Here is the Overpass query to get a better sense of the stats: >> >> * Total motorway_junction edited by team in last two weeks: 179 [5] >> >> This is the detailed workflow for *Exit mapping* [6] and *Destination >> mapping* [7] that was used for this mapping activity. Would be great to >> hear your feedback on how it can be improved for further such tasks, please >> drop a comment on the *project tracker* [3] . >> >> I want to thank all of you in the community for giving feedback, calling >> us out on the occasional errors, and working with us to improve signpost >> mapping conventions. I feel proud to be a member of such a great mapping >> community! >> Cheers, >> >> Jinal Foflia >> >> [1] https://www.openstreetmap.org/user/jinalfoflia/diary/38501 >> >> [2] https://www.openstreetmap.org/user/jinalfoflia/diary/38342 >> >> [3] https://github.com/mapbox/mapping/issues/178 >> >> [4] https://github.com/mapbox/mapping/issues/169 >> >> [5] http://overpass-turbo.eu/s/fzA >> >> [6] >> https://gist.github.com/poornibadrinath/a8f3652deb566d95b848c5e9cd68011f >> >> [7] >> https://gist.github.com/poornibadrinath/f982a947c6a063ed1a9016a2d3246d4a >> >> >> >> >> ___ >> Talk-us mailing list >> Talk-us@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-us >> >> > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us > > ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Improving coverage of exit numbers and destinations on motorways
I'm wondering why the push to tag a node with directional information when tagging the first segment of the diverging way would be more concise and already had support in some navigational data consumers? This handles weird situations where ramps diverge to the left or from a lane other than the edge much more cleanly. For example, Exit 2 in West Tulsa on I 244. First segment could be tagged as... name=Okmulgee Beeline junction:ref=2 destination=Okmulgee destination:ref=US 75 South ref=US 75 highway=motorway Or, the number 3 lane exit westbound US 26 north of Beaverton at exit 71A (lanes 1, 2 and 4 remain on US 26, oddly enough). name=Canyon Road highway=motorway_link ref=OR 8 junction:ref=71A destination=Beaverton destination:ref=OR 8 West This along with the departure angle, gives navigation systems ample information to accurately describe the ramp that point data just leaves out. On Tue, May 3, 2016 at 4:46 AM, Jinal Foflia wrote: > There has been a recent push to improve the coverage of exit numbers and > destination signs on the motorways in the US by the data team at Mapbox. > Some context here [1][2][3][4]. The primary sources of data were DoT > documents and Mapillary images. The secondary source was Wikipedia, but as > per the conversation with the local mappers, it is not a good idea to > completely trust wikipedia documents for mapping the exit numbers and > destinations. There are certain highways which do not have Mapillary > coverage and it is difficult to validate/identify the missing exit numbers > and destination. It will be a great help if local mappers can help share > reliable sources and validate the existing data that will help improve the > coverage of this data on the map > > We been working on this from the beginning of April and reviewed more than 220 > highways in 9 states. The goal would be to authenticate all the existing > data and fill in the gaps using verifiable sources wherever possible. > > Here is the Overpass query to get a better sense of the stats: > > * Total motorway_junction edited by team in last two weeks: 179 [5] > > This is the detailed workflow for *Exit mapping* [6] and *Destination > mapping* [7] that was used for this mapping activity. Would be great to > hear your feedback on how it can be improved for further such tasks, please > drop a comment on the *project tracker* [3] . > > I want to thank all of you in the community for giving feedback, calling > us out on the occasional errors, and working with us to improve signpost > mapping conventions. I feel proud to be a member of such a great mapping > community! > Cheers, > > Jinal Foflia > > [1] https://www.openstreetmap.org/user/jinalfoflia/diary/38501 > > [2] https://www.openstreetmap.org/user/jinalfoflia/diary/38342 > > [3] https://github.com/mapbox/mapping/issues/178 > > [4] https://github.com/mapbox/mapping/issues/169 > > [5] http://overpass-turbo.eu/s/fzA > > [6] > https://gist.github.com/poornibadrinath/a8f3652deb566d95b848c5e9cd68011f > > [7] > https://gist.github.com/poornibadrinath/f982a947c6a063ed1a9016a2d3246d4a > > > > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us > > ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Improving coverage of exit numbers and destinations on motorways
There has been a recent push to improve the coverage of exit numbers and destination signs on the motorways in the US by the data team at Mapbox. Some context here [1][2][3][4]. The primary sources of data were DoT documents and Mapillary images. The secondary source was Wikipedia, but as per the conversation with the local mappers, it is not a good idea to completely trust wikipedia documents for mapping the exit numbers and destinations. There are certain highways which do not have Mapillary coverage and it is difficult to validate/identify the missing exit numbers and destination. It will be a great help if local mappers can help share reliable sources and validate the existing data that will help improve the coverage of this data on the map We been working on this from the beginning of April and reviewed more than 220 highways in 9 states. The goal would be to authenticate all the existing data and fill in the gaps using verifiable sources wherever possible. Here is the Overpass query to get a better sense of the stats: * Total motorway_junction edited by team in last two weeks: 179 [5] This is the detailed workflow for *Exit mapping* [6] and *Destination mapping* [7] that was used for this mapping activity. Would be great to hear your feedback on how it can be improved for further such tasks, please drop a comment on the *project tracker* [3] . I want to thank all of you in the community for giving feedback, calling us out on the occasional errors, and working with us to improve signpost mapping conventions. I feel proud to be a member of such a great mapping community! Cheers, Jinal Foflia [1] https://www.openstreetmap.org/user/jinalfoflia/diary/38501 [2] https://www.openstreetmap.org/user/jinalfoflia/diary/38342 [3] https://github.com/mapbox/mapping/issues/178 [4] https://github.com/mapbox/mapping/issues/169 [5] http://overpass-turbo.eu/s/fzA [6] https://gist.github.com/poornibadrinath/a8f3652deb566d95b848c5e9cd68011f [7] https://gist.github.com/poornibadrinath/f982a947c6a063ed1a9016a2d3246d4a ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
