[Talk-us] Fresno castradal imports

Frederik Ramm frederik at remote.org
Thu Apr 26 21:11:25 BST 2012


On 04/26/2012 08:14 PM, Alan Mintz wrote:
> 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.

I don't know what you complain about. Those buildings don't even have 3D 
features. The amount of data could easily quadruple when that is added ;)

> 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.

If one can identify a subset of data which is usually not of interest 
when working with the other data like you say here, then the question is 
why is that data in OSM at all? Could one not have a completly separate 
database called "OpenBuildingMap" where users can air-drop their 
building datasets from god-knows-whom and then if you want to render a 
map that has buildings and streets you combine OSM and OBM at the 
rendering stage rather than having every building in OSM? Granted, it 
will become more difficult to e.g. move a street *and* the abutting 
buildings but even that could be handled by a good editor.

There would be a danger of someone drawing a new road and not seeing 
that he draws it across a row of buildings; that could maybe solved by 
putting a rendered image of the buildings in the background.

> 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.

That would have the same problem I sketched above; you could still draw 
new stuff that conflicts with other things already there but filtered. A 
bitmap represenation of filtered stuff would have to be available in the 
background to alleviate that.


Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"

More information about the Talk-us mailing list