[Talk-us] (Second attempt) Potential data source: Adirondack Park Freshwater Wetlands

2016-02-26 Thread Kevin Kenny
My apologies if this message turns out to be a duplicate. I mistakenly 
sent it from a mailbox that isn't subscribed to the lists.


Potential data source: Adirondack Park Freshwater Wetlands

This message is a 'trial balloon' for a potential import of (a subset
of) the data in the series of data sets: "Adirondack Park Freshwater
Wetlands," found at
http://apa.ny.gov/gis/shared/htmlpages/data.html#wetl
This data set, in addition to indicating marshes, bogs and fens, has
extensive information about open water, with detailed information
about lakes and ponds, permanent, intermittent and ephemeral streams,
falls and rapids. In the area of coverage (the Adirondack Park of New
York State), it is considerably more comprehensive and detailed than,
say, the National Hydrographic Database. My experience, from at least
a few hundred miles of hiking and mapping in the area in question, is
that it is quite close to what one finds with boots, literally, on the
ground - or, more likely, half-sunk in beaver swamp.

I'm aware of the controversial nature of imports, and I'm suggesting
this with some trepidation. Please try to be gentle when you flame me.
I'm willing to take 'absolutely not!' for an answer.

To give a rough visual impression of the extent of the coverage
difference that could be achieved, compare what is OpenStreetMap for a
typical spot today:
http://www.openstreetmap.org/#map=14/43.4894/-74.5106=C
with a hiking map that I have rendered from OSM and other layers
https://kbk.is-a-geek.net/catskills/test3.html?la=43.4895=-74.5104=14
(Note that some of the layers I use cannot be shared - or cannot be
shared yet -  under ODBL. The hydrography here, however, is all
derived from either NHD or the Adirondack Park Agency data set. The
use of the two data sets is only part of what gives certain of the
shorelines a 'cubist' look. More significant is that the APA data set
gives typical seasonal high and low water levels, plus extreme
inundation limits if known. This causes a great many watercourses to
have two rendered shorelines, plus perhaps a dashed surround showing
the flood stage. I think that the map at kbk.is-a-geek.net shows how
much this import might help avoid having the Adirondack Park simply be
a blank green area on a regional map.

Now, let me explain how far I am along with following the import
guidelines. (The answer is: not very far yet: it's important to reach
out to the community early.)

I. PREREQUISITES

1. Familiarity with the basics of OpenStreetMap: I've been mapping off
and on for several years, with my chief interest being sharing data
about hiking trails, parks, nature preserves, and associated
amenities. I believe that I at least know my way around. My biggest
single project was getting the complete centerline of the
Northville-Placid Trail entered and organized into a route relation
http://www.openstreetmap.org/relation/4286650  . This task involved
conflating several other attempts to enter (or import, badly, from
TIGER) portions of the trail, together with walking all 138 miles (222
km) with a GPS unit to get the tracks that were missing.  I've also
done the boundaries, trail systems and watercourses of a number of my
local nature preserves and forest tracks, such as
http://www.openstreetmap.org/way/190452078,
http://www.openstreetmap.org/way/339443446,
http://www.openstreetmap.org/way/345643852,
http://www.openstreetmap.org/way/270499380,
http://www.openstreetmap.org/relation/4836454  and
http://www.openstreetmap.org/way/147772635  . I've learnt in the course
of this some of the basics of conflating data and of managing things
like multipolygon and multilinestring relations. The map at
kbk.is-a-geek.net is also largely my doing. I started from Lars
Ahlzen's 'TopOSM,' but I've taken it in a very different direction and
added a couple of dozen layers that he didn't need to work with for
his project. I think that it demonstrates at least basic competency in
Osmosis, Mapnik and PostGIS.

2. Being aware of what can go wrong with imports: I'm acutely aware of
it! I deal with TIGER's hallucinations all the time and I intend to go
to any length to avoid a mess like that.

3. Identiy data I'd like to import: The eighteen files enumerated in
the table athttp://apa.ny.gov/gis/shared/htmlpages/data.html#wetl

II. COMMUNITY BUY-IN

1. Contact the community.  Hi, there!
2. Discuss plan on imports, talk-us, and the appropriate regional
mailing list: Hi there, again!
3. Be prepared to answer questions: I will surely give it a go! I
don't have all the answers.
4. Review with the assistance of more technically-oriented and
experienced OSM volunteers. I hope this message will put me in touch
with a few. I'm fairly technically oriented myself (I'm a PhD in
computer science), but I surely don't have tremendous depth of
experience with the specifics of OSM's data management.
5. Not import the data without local buy-in. This goes without saying.

III. LICENSE APPROVAL

I've taken only a few preliminary steps 

Re: [Talk-us] API Behavior

2016-02-26 Thread Simon Poole
Am 26.02.2016 um 18:09 schrieb Richard Welty:
>
> the problem is that detecting the condition is pretty expensive.
> consider long, straight boundaries that pass through your
> bounding box. the search to find these segments of ways
> might have to range out pretty far.
>
>
Pretty far == the whole dataset/the world

Naturally that is simply the extreme case.

 I always recommend to add a node even in completely straight lines
every couple of dozens of meters/yards to be on the safe side and to
keep everything editable.

Forgetting the extreme case, maybe we should have some kind of bounding
box based index for ways and relations (note we don't use PostGIS and it
wouldn't actually help in this case, so this would have to be home grown
in some form), naturally calculating the bounding box would make many
operations that are now very cheap rather expensive.

Simon



signature.asc
Description: OpenPGP digital signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] API Behavior

2016-02-26 Thread Richard Welty
On 2/26/16 12:01 PM, Martijn van Exel wrote:
> It’s an API limitation. If no node is within the bbox the API has no way of 
> knowing there should be something there. I don’t believe there is a different 
> workaround from the one you already suggest yourself, but I would be happy to 
> be wrong (as I too find this an unfortunate limitation).
>
the problem is that detecting the condition is pretty expensive.
consider long, straight boundaries that pass through your
bounding box. the search to find these segments of ways
might have to range out pretty far.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


[Talk-us] API Behavior

2016-02-26 Thread Mike Thompson
When using the standard API to download an area to edit (through JOSM) it
seems that if a way runs through the bounding box you provide the API, but
doesn't have any nodes in that bounding box, it will not be returned.  This
can result in collecting the same data a second time because the first
instance is not returned.

1) Is this a JOSM issue or an API issue?
2) Is there any work around other than to download using a larger bounding
box and hope that the way in question references at least one node in that
bounding box?

Mike
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us