Re: [Talk-us] Starting OSM Trail Map Initiative In US
HI All, Thanks for all the great comments and input. This is what I was hoping for. It seems like the biggest concern people have expressed is the idea of doing some bulk loading of trails. I am with you on those concerns and think that the primary rule for bulk loading should be first do no harm. Lots of people have made great edits and additions to OSM and you don't want to mess those up. That being said I live in Montana and that is primarily where I have been reviewing trail data. The vast majority of the trail data here came from Tiger bulk loads and is very incomplete and out of date. I know that there are trails data from the USFS, BLM, and various state agencies that are much better. I'm not suggesting those should just be dumped into OSM but I don't think they can be part of a strategy of significantly upgrading and extending what is there. The other issue that was technical in nature that I have also been thinking about was mentioned by Brett and that is coding of trails for different uses. From what I can see this is pretty lacking and not very standardized and that really limits the usefulness of the data. I would really like to get a discussion going on this issue and hear peoples recommendations. My general thoughts are that it Brett's suggestion that there needs to be both classifications for activities and difficulty (or quality) is what is needed. I know that there are some classifications for activities but they don't seem to be widely used or very standardized. The other associated issue in my mind is a better trail head feature type. Fred On Fri, Jul 20, 2012 at 2:17 PM, Fred Gifford fred.giff...@gmail.com wrote: Hi all, I am starting the process of pulling together a group to focus on updating and expanding trail data in OSM. The initial focus would be in the US but we are hoping the model could expand to other areas as well. Initially the project would have two main focus areas – - Focused effort to gather public domain trail data and use it to update existing trail data in OSM through hybrid editing \ bulk upload methodology. - Build a custom version of Potlatch focused on trail mapping - Building trail mapping communities in the US. Here is where things get a little different than other similar efforts – I want much of the work to be done by paid interns and I want to fund it initially through Kickstarter and later though donations. I’d be interested to hear anyones thoughts, concerns, etc, and of course would love to know if anyone is interested in participating. Thanks. Fred ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Starting OSM Trail Map Initiative In US
On 07/20/2012 09:27 PM, Richard Weait wrote:
I can't think of a good substitute for a motivated local mapper.
Daniel Begin said this recently on talk-ca:
You'll find that there is nothing better than an active community to
find odd features in authoritative data!
Daniel knows of what he speaks, he works at the Canadian National
Mapping Agency and has been participating in OSM for several years.
He publishes authoritative data collected by paid professionals, with
what I presume is top notch equipment. And the OSM community of
enthusiastic amateurs finds and fixes odd features and errors.
I don't think that you can get that nearly obsessive attention to
detail across a large area. It takes a _personal_ interest in the
data. I think of that area of obsessive interest and perhaps
encyclopaedic knowledge as the natural range of a mapper.
I'd argue that this is entirely the right model. I'm sure all will
agree: it's hard to recruit individual mappers - although that has
to be a primary goal, because only someone with detailed local
knowledge can do the fixes just mentioned.
But by the same token, it would be foolish to discard the work -
often of extraordinarily high quality - that has been done at
taxpayer expense to curate the large data sets. For the most part,
it's better than what we'd get from a horde of novice mappers.
In any case, the government agencies that administer our public
lands are the ultimate sources of information like {horses,
mountain bikes, skiing, snowmobiles, ATV's} are/are not
not permitted on this trail, or camping is permitted on this
trail only 200 feet or more from the trail at elevations below
3500 feet.
So I'd argue that selling the OSM model to the authorities is
just as important as recruiting OSM mappers. If we can get the
odd features and errors fixed upstream in the official data, we've
essentially recruited the professionals as mappers. We need both:
the professionals who have boatloads of high-quality data (with,
of course, the inevitable errors and omissions) at their disposal,
and the enthusiastic amateurs who will find and fix the errors.
I wonder if the people who argue that all the work has to be
done by individual mappers have simply despaired of ever getting to
the point where corrections can flow into the official sources.
I could argue that in many localities, that's the reason that
imports are problematic: they can happen once only, because the
public data are set in stone. The result is that when the public
data are improved - as with the latest version of TIGER - there's
no way to reimport without a tremendous manual patchwork to merge
the new data into the work that individual mappers have done.
--
73 de ke9tv/2, Kevin
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Starting OSM Trail Map Initiative In US
On 07/20/2012 11:22 PM, Mike Thompson wrote: - Focused effort to gather public domain trail data and use it to update existing trail data in OSM through hybrid editing \ bulk upload methodology. Just and idea for the community's consideration: as an avid trail user and mapper, the one type of bulk upload that would interest me would be the balance of the NHD data. It appears that this has not been completed. I am too busy hiking trails gathering GPS traces to do this myself, and I am not sure I want to venture into bulk upload land. I got started on this, too, and got a fair way along (in a personal mirror) on doing New York south of the Mohawk. I stumbled when I asked a few people that I'd met here to review the work. There were a couple who had a problem that the imported data (obviously) crossed ways with the highway network; they were at best reluctant to accept the import until and unless the individual crossings were tagged appropriately as bridges, culverts, fords or whatever, with an appropriate rendering layer assigned. Having no way to get that information short of driving to each individual stream crossing, I put the project on hold, and simply use NHD as one of the layers that I render in my personal map. TopOSM takes the same approach. Lars and I simply discard OSM hydrographic features in favour of NHD ones. I think I want to follow up on this issue, because I'd still like OSM to have the data. I'll continue in a separate thread, rather than hijacking this one. -- 73 de ke9tv/2, Kevin ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Starting OSM Trail Map Initiative In US
On 07/22/2012 10:19 AM, Fred Gifford wrote: It seems like the biggest concern people have expressed is the idea of doing some bulk loading of trails. I am with you on those concerns and think that the primary rule for bulk loading should be first do no harm. Lots of people have made great edits and additions to OSM and you don't want to mess those up. That being said I live in Montana and that is primarily where I have been reviewing trail data. The vast majority of the trail data here came from Tiger bulk loads and is very incomplete and out of date. I know that there are trails data from the USFS, BLM, and various state agencies that are much better. I'm not suggesting those should just be dumped into OSM but I don't think they can be part of a strategy of significantly upgrading and extending what is there. I agree 100%. I have a good bit of data from New York State on trails that is surely incomplete and imperfect but better than anything we have in OSM. I've not uploaded any of it because I've not convinced myself that it's doing no harm. But most of it would slot into areas of the map that today are nearly blank. I don't foresee any real difficulties with conflation; the chief technical difficulty I'd see is managing a repeat upload as the government files are updated. (I still haven't opened discussions with the state agencies about redistributing the data; there are some licensing hurdles to overcome.) And the effort of doing the trail network without the help of the government (essentially, it gets mapped by rangers carrying GPS as they patrol) would be little short of heroic. One of the files that I have describes over eight thousand miles of trail, some of which is more than a day's walk from the nearest roadway. (The Adirondacks have places that remote.) The other issue that was technical in nature that I have also been thinking about was mentioned by Brett and that is coding of trails for different uses. From what I can see this is pretty lacking and not very standardized and that really limits the usefulness of the data. I would really like to get a discussion going on this issue and hear peoples recommendations. My general thoughts are that it Brett's suggestion that there needs to be both classifications for activities and difficulty (or quality) is what is needed. I know that there are some classifications for activities but they don't seem to be widely used or very standardized. The other associated issue in my mind is a better trail head feature type. The problem that I see with classifications for difficulty is that there are few standards. Trails that are called 'moderate' or even 'easy' in New Hampshire might be called 'strenuous' or 'difficult' in Virginia. For most of the trails that I have data on, I do have basic regulatory information as well: foot=yes horse=yes bicycle=yes ski=yes atv=no snowmobile=no or similar fields. For many of them, I also have waymark information - either the principal blaze colour, or else a description red horizontal dash on white, yellow triangle on black, blue disc, green-and-white Finger Lakes Trail logo, and so on, which should also be considered for a map. How much does trailhead differ from parking? I've usually just shown trailheads as parking areas - they usually have space for at least a few cars. Some features that I'd like to see some consensus on is trail shelter/ lean-to, register box, and a perennial/seasonal tag on springs. Whenever the shelter topic has arisen, there seem to be people who jump in rather confused by the difference between a trail shelter, a picnic shelter, and a bus shelter. (Hint: I won't be arrested for vagrancy if caught sleeping in the first.) -- 73 de ke9tv/2, Kevin ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Starting OSM Trail Map Initiative In US
Kevin Kenny kken...@nycap.rr.com writes: I agree 100%. I have a good bit of data from New York State on trails that is surely incomplete and imperfect but better than anything we have in OSM. I've not uploaded any of it because I've not convinced myself that it's doing no harm. But most of it would slot into areas of the map that today are nearly blank. I don't foresee any real difficulties with conflation; the chief technical difficulty I'd see is managing a repeat upload as the government files are updated. (I still haven't opened discussions with the state agencies about redistributing the data; there are some licensing hurdles to overcome.) If the govt data really is good, then that mitigates a lot of the concerns, especially if a local mapper meets with a park manager and talks about data quality. The other issue that was technical in nature that I have also been thinking about was mentioned by Brett and that is coding of trails for different uses. From what I can see this is pretty lacking and not very standardized and that really limits the usefulness of the data. I would really like to get a discussion going on this issue and hear peoples recommendations. My general thoughts are that it Brett's suggestion that there needs to be both classifications for activities and difficulty (or quality) is what is needed. I know that there are some classifications for activities but they don't seem to be widely used or very standardized. The other associated issue in my mind is a better trail head feature type. The problem that I see with classifications for difficulty is that there are few standards. Trails that are called 'moderate' or even 'easy' in New Hampshire might be called 'strenuous' or 'difficult' in Virginia. I am almost always in favor of OSM finding the relevant professional community or stewardship organization and adopting existing standards. OSM already has sac_scale but I'm not sure how useful that is in the US. For rock climbing there is certainly a classification system. For most of the trails that I have data on, I do have basic regulatory information as well: foot=yes horse=yes bicycle=yes ski=yes atv=no snowmobile=no or similar fields. For many of them, I also have waymark information - either the principal blaze colour, or else a description red horizontal dash on white, yellow triangle on black, blue disc, green-and-white Finger Lakes Trail logo, and so on, which should also be considered for a map. How much does trailhead differ from parking? I've usually just shown trailheads as parking areas - they usually have space for at least a few cars. In my view, parking is parking, and should be tagged as such. trailhead is a designation of cultural importance within the hiking community, meaning a place were a trail can be accessed from roads that is notable as a place to begin or end. Basically, if there were a local club, and they wrote a map and guidebook, it's a trailhead if they would talk about it as such. That said, trailheads tend to have parking. Or are places where parking is banned but there are shuttle buses (e.g. parts of Grand Canyon and Yosemite, at least seasonally). pgp9AAEWCXdit.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Map Corps Revived - And Using the OSM Stack
Ian, The link appears to be dead. Was the video taken down? Cheers, Adam On Thu, Jul 19, 2012 at 10:17 AM, Ian Dees ian.d...@gmail.com wrote: Hi everyone, I saw a tweet from @USGS today mentioning that the National Map Corps are starting up again. If you don't know what the National Map Corps is, think of it like OpenStreetMap for the US Government. Volunteer mappers correcting and adding to the topo maps all over the country. I'm sure there are others with much more information, but it was a pretty epic project and is the source for lots of the free and public domain data we use to this day. For the last year or two (or three?) Eric Wolf's been working to adapt the OpenStreetMap stack to the USGS's needs, and it looks like it that work has finally been released. Check out this video for more information: http://gallery.usgs.gov/videos/552. Skip to 4:10 or so to see it in action. Hopefully Eric and others will respond here and tell us more about it! -Ian ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Map Corps Revived - And Using the OSM Stack
Yep. They announced it prematurely. They'll have more information about it in the near future. On Sun, Jul 22, 2012 at 4:25 PM, Adam Schreiber adam.schreiber+...@gmail.com wrote: Ian, The link appears to be dead. Was the video taken down? Cheers, Adam On Thu, Jul 19, 2012 at 10:17 AM, Ian Dees ian.d...@gmail.com wrote: Hi everyone, I saw a tweet from @USGS today mentioning that the National Map Corps are starting up again. If you don't know what the National Map Corps is, think of it like OpenStreetMap for the US Government. Volunteer mappers correcting and adding to the topo maps all over the country. I'm sure there are others with much more information, but it was a pretty epic project and is the source for lots of the free and public domain data we use to this day. For the last year or two (or three?) Eric Wolf's been working to adapt the OpenStreetMap stack to the USGS's needs, and it looks like it that work has finally been released. Check out this video for more information: http://gallery.usgs.gov/videos/552. Skip to 4:10 or so to see it in action. Hopefully Eric and others will respond here and tell us more about it! -Ian ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Map Corps Revived - And Using the OSM Stack
I watched it after Ian sent the link. According to the video, it uses Potlatch 2 to gather a very limited set of POIs in the initial pilot area of Colorado. I was kind of curious if there was going to be any interaction with OSM other than using the tool stack. Brad On Sun, Jul 22, 2012 at 4:50 PM, Ian Dees ian.d...@gmail.com wrote: Yep. They announced it prematurely. They'll have more information about it in the near future. On Sun, Jul 22, 2012 at 4:25 PM, Adam Schreiber adam.schreiber+...@gmail.com wrote: Ian, The link appears to be dead. Was the video taken down? Cheers, Adam On Thu, Jul 19, 2012 at 10:17 AM, Ian Dees ian.d...@gmail.com wrote: Hi everyone, I saw a tweet from @USGS today mentioning that the National Map Corps are starting up again. If you don't know what the National Map Corps is, think of it like OpenStreetMap for the US Government. Volunteer mappers correcting and adding to the topo maps all over the country. I'm sure there are others with much more information, but it was a pretty epic project and is the source for lots of the free and public domain data we use to this day. For the last year or two (or three?) Eric Wolf's been working to adapt the OpenStreetMap stack to the USGS's needs, and it looks like it that work has finally been released. Check out this video for more information: http://gallery.usgs.gov/videos/552. Skip to 4:10 or so to see it in action. Hopefully Eric and others will respond here and tell us more about it! -Ian ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] NHD import: what data quality is acceptable?
A few months ago, I tried to get started on trying to resume the NHD import in my area - and some of the places where I hike. I'm trying to check results with both P2 and JOSM, and tripping over a lot of things, which made me put the project back on hold for a while. (I had some other things to be about.) But now I'm starting to reconsider again, after hearing that there are others out there thinking the NHD import is desirable for an Open Trail Map. I mentioned this in a message earlier today. So, let me review some of the things that have me scratching my head. (1) The mapping from NHD feature codes to OSM tags is incomplete (and not quite consistent). That's fine; for all the FCodes in my area, I've been able to find features that I'm familiar with that I can describe. So I think I have that problem fairly well licked. (I may have to invent a tag or two, like waterway=rise and waterway=sink to describe streams that go underground and appear again in karst terrain.) (2) One historic complaint I've seen about the NHD import is that it clutters the map, and that the assignment of river and stream is difficult. What I'd propose is to tag as river anything that has more than two nodes of its flowline as Artificial Path, and stream anything that's smaller. In my area (eastern New York), for instance, that would mark out the Schoharie Creek, the Mohawk, the Hudson, and the lower reaches of the Catskill, the Kaaterskill, the Esopus, and maybe a few others. Is this a reasonable approach? (3) Is it necessary to tag shorelines with name=? It would be something of an effort to identify what flowline belongs to a shoreline, and it's somewhat ambiguous near confluences. I'm inclined not to do anything about this issue unless there's an overwhelming consensus that it needs to be addressed. (4) What about cadastral lines (administrative boundaries, and land use, leisure, etc.) that appear to follow flowlines? My inclination is not to touch these at all, even if the flowline is being refined. Oftentimes, when a stream changes course, the cadastre remains unchanged. Only the recorder's office in the jurisdiction in question would actually know the situation. I think I'd rather see slightly inconsistent boundaries than mess up something like that. (5) In the area I have in mind, there are very few ways that actually would need to be conflated (a few major rivers). Is it likely to be called vandalism if I confine myself to copying the OSM-specific tags from the OSM ways onto the NHD ones? I trust a land survey rather more than I do someone tracing a shoreline from Bing imagery: in well-graded streams, the shorelines can be variable and ambiguous, and NHD has pretty sound information about high water marks. (6) When I try a limited import, I get a lot of JOSM warnings about waterways crossing highways. Do people think that all of these have to be fixed before importing? In that case, I'll have to confine myself to the very small area that has highway-crossing-stream that I can visit myself (to try to settle what the boundaries of the bridge, dam or culvert are, and what type of waterwork it is). Is it considered acceptable simply to leave the crossings unmarked? (They still render correctly in Mapnik, for what it's worth.) (7) In the event that I find a node tagged with something other than a waterway (or landuse=reservoir, man_made=dam, etc.) that collides with an NHD node, is the correct approach to conflate the nodes, introduce a duplicate, or offset the new node? Does this question even have a correct answer? I'm trying seriously to do no harm, and getting paralyzed by the fact that there seem to be no firm guidelines on what is acceptable. I'm trying to start with areas where I have firm local knowledge, although clearly I cannot survey streams on private lands, so I have to depend on NHD there. But the result is not going to be of much use to me unless I can generalize what I learn to do better NHD imports in areas that I know less well. -- 73 de ke9tv/2, Kevin ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] National Park boundaries
Hi all, I was looking at the Golden Spike National Historic Site[1], of particular interest because the Union Pacific railroad celebrates its 150th birthday this year[2]. While elements are represented in OSM[3], a search for 'Golden Spike' yields nada. I was about to draw a boundary=national_park[3] around it with a name tag, so it would be a little easier to find. But it turns out the NPS has a boundary shapefile for all National Parks, Historic Sites, Rivers, Parkways, Lakeshores and more than a dozen other categories[4]. Is this something to consider for importing? Has this already been considered in the past? As you know, I am very skeptical towards data imports and will only propose or consider them for useful features that are very hard or impossible to survey. I believe this is a candidate. I understand if everybody is busy remapping, but I just wanted to throw it out there. Best Martijn [1] http://www.nps.gov/gosp/planyourvisit/directions.htm [2] Check out the neat timeline: http://up150.com/timeline/ [3] https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dnational_park - may not be appropriate, but there does not seem to be a tag for historic sites as such (https://wiki.openstreetmap.org/wiki/Historic) [4] https://irma.nps.gov/App/Reference/Profile/2185767 -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Park boundaries
On 7/22/2012 7:39 PM, Martijn van Exel wrote: But it turns out the NPS has a boundary shapefile for all National Parks, Historic Sites, Rivers, Parkways, Lakeshores and more than a dozen other categories[4]. Is this something to consider for importing? I am in favor of importing park boundaries in particular because it is usually impractical to survey them in the traditional way: park managers don't want random unsupervised people wandering off trail trying to find park boundaries. The boundaries might be on dangerous terrain. Park boundaries are also often not possible to spot from aerial imagery. Rivers, waterways, etc are best obtained from NHD. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Map Corps Revived - And Using the OSM Stack
Hi, On Sun, Jul 22, 2012 at 5:14 PM, Brad Neuhauser brad.neuhau...@gmail.com wrote: I watched it after Ian sent the link. According to the video, it uses Potlatch 2 to gather a very limited set of POIs in the initial pilot area of Colorado. I was kind of curious if there was going to be any interaction with OSM other than using the tool stack. Any interaction in terms of data exchange would necessarily have to be a one-way street; USGS data is PD and our data is ODbL (almost). So data can travel to us but not back to the USGS. That said, USGS has reached out to us to make that one-way data flow possible. Whatever the NMC does to improve GNIS points (I believe that is what the pilot is) could flow towards OSM, if and only if the corresponding OSM data has not been modified from its original import. If it has, you could still manually merge or hot-or-not the individual data points. Martijn -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Park boundaries
Hi, On Sun, Jul 22, 2012 at 5:55 PM, Mike N nice...@att.net wrote: On 7/22/2012 7:39 PM, Martijn van Exel wrote: But it turns out the NPS has a boundary shapefile for all National Parks, Historic Sites, Rivers, Parkways, Lakeshores and more than a dozen other categories[4]. Is this something to consider for importing? I am in favor of importing park boundaries in particular because it is usually impractical to survey them in the traditional way: park managers don't want random unsupervised people wandering off trail trying to find park boundaries. The boundaries might be on dangerous terrain. Park boundaries are also often not possible to spot from aerial imagery. I think the rivers themselves are not in the boundary file but rather the areas around the actual rivers that are designated the National River site. I manually imported the Golden Spike boundary[1]. Turns out there actually was an old (apparently hand-drawn) boundary. Maybe nominatim doesn't pick up named national park boundaries? [1] http://www.openstreetmap.org/browse/way/172594029 - I translated PARKNAME to name and UNIT_NAME to name:full, the rest as is with nps: prepended to the key. Martijn -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Park boundaries
a search for 'Golden Spike' yields nada. I was about to draw a boundary=national_park[3] around it with a name tag, so it would be a little easier to find. But it turns out the NPS has a boundary shapefile for all National Parks, Historic Sites, Rivers, Parkways, Lakeshores and more than a dozen other categories[4]. I wouldn't object to importing park boundaries. But, I find boundary=national_park odd, relative to the rest of boundary=*. For truly large parks, it makes some sense. A related issue is tagging the polygon rather than the boundary, and the landuse=conservation/leisure=recreatation_ground tagging (not really right for parks, but actually the combination describes the NPS mission). So I have a mild preference (not backed up by volunteering) to make the park boundary/polygon tagging a bit more baked before importing. pgpoRyYldCcNT.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Map Corps Revived - And Using the OSM Stack
Ian, I read through their Web site. They used Potlatch 1 for two pilot projects in crowdsourcing (yes, they used the word) topographic data. Apparently they were pleased enough with the results to plan to move ahead, at some point, with crowdsourced topographic mapping. I hope they have taken a look at Potlatch 2. They also mentioned OSM several times on a couple of Web pages, which was nice publicity. Charlotte At 02:50 PM 7/22/2012, you wrote: Yep. They announced it prematurely. They'll have more information about it in the near future. On Sun, Jul 22, 2012 at 4:25 PM, Adam Schreiber mailto:adam.schreiber+...@gmail.comadam.schreiber+...@gmail.com wrote: Ian, The link appears to be dead. Was the video taken down? Cheers, Adam On Thu, Jul 19, 2012 at 10:17 AM, Ian Dees mailto:ian.d...@gmail.comian.d...@gmail.com wrote: Hi everyone, I saw a tweet from @USGS today mentioning that the National Map Corps are starting up again. If you don't know what the National Map Corps is, think of it like OpenStreetMap for the US Government. Volunteer mappers correcting and adding to the topo maps all over the country. I'm sure there are others with much more information, but it was a pretty epic project and is the source for lots of the free and public domain data we use to this day. For the last year or two (or three?) Eric Wolf's been working to adapt the OpenStreetMap stack to the USGS's needs, and it looks like it that work has finally been released. Check out this video for more information: http://gallery.usgs.gov/videos/552http://gallery.usgs.gov/videos/552. Skip to 4:10 or so to see it in action. Hopefully Eric and others will respond here and tell us more about it! -Ian ___ Talk-us mailing list mailto:Talk-us@openstreetmap.orgTalk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us Charlotte Wolter 927 18th Street Suite A Santa Monica, California 90403 +1-310-597-4040 techl...@techlady.com Skype: thetechlady The Four Internet Freedoms Freedom to visit any site on the Internet Freedom to access any content or service that is not illegal Freedom to attach any device that does not interfere with the network Freedom to know all the terms of a service, particularly any that would affect the first three freedoms. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD import: what data quality is acceptable?
Kevin Kenny kken...@nycap.rr.com writes: A few months ago, I tried to get started on trying to resume the NHD import in my area - and some of the places where I hike. I'm trying to check results with both P2 and JOSM, and tripping over a lot of things, which made me put the project back on hold for a while. (I had some other things to be about.) Working on this in my area is on my Copious Spare Time list. (2) One historic complaint I've seen about the NHD import is that it clutters the map, That seems like a bogus criticism; renderers can choose to render or ignore. If the criticism is cluttering the database, that's a harder call, but water features are broadly important and it seems unreasonable to exclude them on clutter grounds. Sooner or later we're going to need a layer concept in editors and probably the API. and that the assignment of river and stream is difficult. What I'd propose is to tag as river anything that has more than two nodes of its flowline as Artificial Path, and stream anything that's smaller. In my area (eastern New York), for instance, that would mark out the Schoharie Creek, the Mohawk, the Hudson, and the lower reaches of the Catskill, the Kaaterskill, the Esopus, and maybe a few others. Is this a reasonable approach? It seems like following the NHD norms is sensible. For those who didn't go read the wiki http://wiki.openstreetmap.org/wiki/NHD Artificial Path is a NHD codepoint for river flowlines when NHD has riverbank data. Are you just talking about someone not quite being sure in edge cases? Or are people upset about river/stream seeming off in OSM because it is off in NHD? Or something else? (4) What about cadastral lines (administrative boundaries, and land use, leisure, etc.) that appear to follow flowlines? My inclination is not to touch these at all, even if the flowline is being refined. Oftentimes, when a stream changes course, the cadastre remains unchanged. Only the recorder's office in the jurisdiction in question would actually know the situation. I think I'd rather see slightly inconsistent boundaries than mess up something like that. That sounds like a good plan to me. (5) In the area I have in mind, there are very few ways that actually would need to be conflated (a few major rivers). Is it likely to be called vandalism if I confine myself to copying the OSM-specific tags from the OSM ways onto the NHD ones? I trust a land survey rather more than I do someone tracing a shoreline from Bing imagery: in well-graded streams, the shorelines can be variable and ambiguous, and NHD has pretty sound information about high water marks. In my view, if you are acting in good faith and believe the post-edit map to be better than the pre-edit map, it is not even close to vandalism. Often what I do when I want to change something and am a bit unsure is to see who last edited it and message them. Usually I don't get an answer, but sometimes I do and it's been overwhelmingly positive (as in sure, that sounds like progress). So you could write to people that added the big rivers and ask about their data and whether they think it is better/worse than NHD. (6) When I try a limited import, I get a lot of JOSM warnings about waterways crossing highways. Do people think that all of these have to be fixed before importing? In that case, I'll have to confine myself to the very small area that has highway-crossing-stream that I can visit myself (to try to settle what the boundaries of the bridge, dam or culvert are, and what type of waterwork it is). Is it considered acceptable simply to leave the crossings unmarked? (They still render correctly in Mapnik, for what it's worth.) waterways crossing highways is how it is. They shouldn't be connected, because you can't navigate from one to the other. Having the waterway improves the map, and the fact that it doesn't have detail about bridges or aqueducts etc. should not be a bar to the improvement. No where else in OSM do we require quality standards to be met - just that the map after the edit is better. (7) In the event that I find a node tagged with something other than a waterway (or landuse=reservoir, man_made=dam, etc.) that collides with an NHD node, is the correct approach to conflate the nodes, introduce a duplicate, or offset the new node? Does this question even have a correct answer? I would merge the nodes. I think a key point is that if you are looking at an existing map feature and at NHD data for a single actual thing, and you are thinking about that case, and maybe looking at imagery and deciding what's the best thing to do, that's 100% fine, and isn't really importing as it is railed against. If you were going to write a program to bring in large amounts of NHD stuff that you didn't look at and have it find matching nodes and merge them without human review, that would be something else. I'm trying seriously to do no harm, and getting paralyzed
Re: [Talk-us] NHD import: what data quality is acceptable?
From: Kevin Kenny [mailto:kken...@nycap.rr.com] Subject: [Talk-us] NHD import: what data quality is acceptable? A few months ago, I tried to get started on trying to resume the NHD import in my area - and some of the places where I hike. I'm trying to check results with both P2 and JOSM, and tripping over a lot of things, which made me put the project back on hold for a while. (I had some other things to be about.) But now I'm starting to reconsider again, after hearing that there are others out there thinking the NHD import is desirable for an Open Trail Map. I mentioned this in a message earlier today. So, let me review some of the things that have me scratching my head. (1) The mapping from NHD feature codes to OSM tags is incomplete (and not quite consistent). That's fine; for all the FCodes in my area, I've been able to find features that I'm familiar with that I can describe. So I think I have that problem fairly well licked. (I may have to invent a tag or two, like waterway=rise and waterway=sink to describe streams that go underground and appear again in karst terrain.) The mappings on the wiki are not only incomplete and inconsistent, they're for an older NHD version and sometimes clearly wrong. I posted a better one (http://lists.openstreetmap.org/pipermail/talk-us/2012-July/008502.html) earlier this month but it didn't attract any comments, and it's not complete either. It handles most of the FCodes but still is missing a couple. It also needs some post-processing to clean up over-noded ways and some other matters. The main weakness with NHD data that I find is that there is no way to distinguish between an OSM waterway=stream and waterway=river ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD import: what data quality is acceptable?
On Sun, 2012-07-22 at 18:33 -0700, Paul Norman wrote: The main weakness with NHD data that I find is that there is no way to distinguish between an OSM waterway=stream and waterway=river Why not use the name? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD import: what data quality is acceptable?
From: James Umbanhowar [mailto:jumba...@gmail.com] Sent: Sunday, July 22, 2012 6:43 PM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] NHD import: what data quality is acceptable? On Sun, 2012-07-22 at 18:33 -0700, Paul Norman wrote: The main weakness with NHD data that I find is that there is no way to distinguish between an OSM waterway=stream and waterway=river Why not use the name? The name is the best way I've found and is in fact what I'm using (https://github.com/pnorman/ogr2osm-translations/blob/69434ec55a48e9e4858ef3 5f2489949b2020e527/us_nhd.py#L234) but it's not 100% No way is perhaps a bit strong, no fully reliable way would be more accurate. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
