At 2012-04-26 07:59, Nathan Edgars II wrote:
On 4/26/2012 2:54 AM, Paul Norman wrote:
I happened across an import of Fresno castradal data from mid-2010 in the
Fresno area. http://www.openstreetmap.org/?lat=36.77&lon=-119.81&zoom=15 is
the general area but I haven't fully explored the extents. For a view of the
data, see http://maps.paulnorman.ca/imports/review/fresno.png
The biggest problem with this import is that it's impossible to download
any reasonably-sized area of Fresno for editing, because of how the
landuse polygons end at every street and alley. It's even worse in the
suburbs where the streets curve, adding many nodes to each way.
(By the way, the word is cadastral, not castadral. And I see nothing wrong
with using such data as part of a semi-manual process of creating larger
landuse polygons for neighborhoods, and commercial strips surrounding
highways. See Orlando, FL for a (mostly fully-manual) example of how this
works.)
+1
No wonder they thought I was you on IRC last night. That explains some things.
Bakersfield suffers from a similar problem, in that every building is
mapped. Landuse polygons, though at least not for every lot, are still
over-digitized, and individual trees were imported.
To those that say "download smaller pieces - you're doing something wrong",
I say:
I've got 68000 km sq of area to get through - that's 680 x 100 km sq, and
even some of those, what I believe should be, reasonably-sized pieces are
160MB, making them completely unusable in JOSM, even with the filter. You
are wrong.
It's not unreasonable to want to download once, do a large edit, and upload
again. There are plenty of things that require this, like license review,
tag correction, large surveys, etc. Why should I be forced into so many
tiny downloads. Even semi-automated with JOSM remote-control, it's still a
PITA with every 10-20th download hanging, having to figure out what size
pieces to use, etc.
Part of the problem is solved by the mirrored download plugin in JOSM,
which does not suffer from the 50000 (or whatever) item limit, and is
generally much faster at delivering data. At least you can send one
download request and go have a beer, because you'll need it when you get
back to wait seconds after every screen drag, mouse click, find, etc. even
when java is given 1GB RAM on a 2.8 GHz dual-core.
I imagine Potlatch is similarly afflicted in such dense areas, as it has to
deal with about 10x as many objects as areas without this sort of detail.
Some would prefer to solve the problem by removing such data and preventing
this kind of micro-mapping. I say we need to find a solution to accommodate
it if it's so important to be all things to everyone - but we can't just
blindly say "deal with it", as was the initial response last night.
One limited solution is to be able to filter the downloads, which seems
possible using the Overpass API - the subject of another message.
Implementation of a "not" filter in XAPI was also discussed. In the
particular case of licensing review where you are only adding/editing tags,
and not deleting or moving nodes, it is reasonable to be able to exclude
these buildings, landuses, and (mostly fictitious) streams from the
download, which would speed both the download and subsequent editing
tremendously. In areas where (thankfully) landuses do not share nodes with
anything else, a much broader set of mapping workflows does not require
them to be present. Certainly, one could exclude individual trees and
address nodes from most editing sessions that aren't dealing with those
items specifically, which would help greatly in the Bakersfield and San
Diego areas, respectively. An even better filtering implementation would
add back in any filtered objects that shared nodes with any objects present
in the download, in much the same way that the API "map" calls include the
full extent of ways, even outside the bbox, if they have any nodes inside
the bbox, and any relations that refer to anything in the result set.
--
Alan Mintz <alan_mintz+...@earthlink.net>
_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
