Hi,

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.

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Reply via email to