Hi Josh,
On 6/20/11 11:02 AM, Josh Doe wrote:
1) I believe you've split the files to ensure no more than 50,000
nodes per file (upload limits I believe), but it is somewhat
fragmented so that for a given region streams are split between the
files. This will result in additional duplicate nodes to be resolved,
and at least should be discussed in the process documentation. I do
wonder why we need to split the files at all, since I hope no one
plans to batch upload these files.
The node split was designed to cope with the case where a user wants to
import an entire watershed, as is, and needs the data small enough to
not blow up an importer.
My personal 0.02 is:
- Plenty of areas have inconsistent water coverage, so bulk importing is
going to be sort of a mess - "import it now, fix it later".
- A "merge in with tool" model (e.g. via potlatch vector layers) is a
lot better - if Richard and I can create a seamless path from this data
into Potlatch 2, that would optimize the case that I think is really
important, e.g. 'my town has 50% of its lakes, let me pull up NHD as a
"seed" to put the other 50% in'. In other words, since merging may
require a lot of human labor, a work-flow that makes it easiest for
editors might be the highest priority.
- If we end up with a "merge model" then...yeah, we might stop
splitting...but the unsplit JOSM files are big, so there may be other
data size constraint issues to cope with.
2) FCode 34306 should be waterway=dam (according to the NHD Rules
page), but doesn't have any tags other than fcode/ftype/com_id/source.
Uh oh...do you have a HUC + COM_ID or another pair of identifying tags
so I can look at this in detail? I'm not sure what went wrong here as
the import rules look correct on my machine.
3) There are lots of FCode 36400, which only have the basic tags,
though no waterway=* or water=* tags (FCode is FORESHORE, one proposed
mapping scheme was water=tidal)
4) There are several 45401 with nothing but the basic tags (Special
Use Zone Type|dump site; Operational Status|operational )
5) Okay several more like this in the nhdarhi files (39800, described
as LOCK CHAMBER, lock=yes by one mapping), 40307, 45401, 46006
Right - this is (I think) a limitation with shp2osm.jar - as long as any
"useful" tag (like FCODE) is present, the object is imported even if the
"OSM-meaningful" tags are not.
I have been hesitant to address this because I don't have a full build
environment for shp2osm - I've been using a pre-built binary. If Ian
tweaks shp2osm or I get off my rear and either tweak it myself or add a
post processing step, we could fix this.
Is the plan to import these in OSM now, and define tags for them later?
Maybe. :-) I'm new to the whole NHD thing and don't have any
particularly good/well-thought-out plans myself...my thinking was
basically "hrm - there's a lot of partially missing wter...maybe if I
use my command-line skills and host the files, then editors who can edit
with tools but get scared of command lines, batches, shapefiles, and the
like won't be frozen out." At least in the X-Plane community there are
definitely people who would like to participate and help, but who need
to join in at the end phases with UI-based work-flow.
Personally between an import-centric and edit/merge-centric strategy, I
think I'm in favor of an edit/merge-centric strategy...there's already a
fair amount of US water in place, and just "overlaying" the entire NHD
database onto OSM isn't really a win...if an end consumer of data wanted
it, they could simply download extracts of both databases into their GIS.
Side note on that: if anyone wants the RAW NHD files, let me know - I
got them on DVD but I can push them somewhere. Heck, I suppose I could
just push them to that dev server.
Side note two: I think that for X-Plane we may have to overlay NHD with
OSM as part of our own process to 'auto fill' areas with seriously
missing water...I could try to output some kind of "status" list based
on that process if it's useful, e.g. a list of HUCs or HUC/COMIDs that
were auto-imported by us because, based on our heuristics it looked like
they were both important and safe to merge in without human supervision.
But that might just create an even more scattered environment of
partial water in the US for editors to cope with.
cheers
Ben
--
Scenery Home Page: http://scenery.x-plane.com/
Scenery blog: http://www.x-plane.com/blog/
Plugin SDK: http://www.xsquawkbox.net/xpsdk/
X-Plane Wiki: http://wiki.x-plane.com/
Scenery mailing list: x-plane-scen...@yahoogroups.com
Developer mailing list: x-plane-...@yahoogroups.com
_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
