[Talk-us] Fresno castradal imports

Alan Mintz Alan_Mintz+OSM at Earthlink.Net
Thu Apr 26 19:14:17 BST 2012

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 


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+OSM at Earthlink.net>

More information about the Talk-us mailing list