[OSM-dev] auto-generating landuse=residential polygon around highway=residential -streets

Marcus Wolschon Marcus at Wolschon.biz
Fri Feb 27 21:39:31 GMT 2009


On Fri, Feb 27, 2009 at 5:47 PM, Roland Olbricht <roland.olbricht at gmx.de> wrote:
> In this scenario, it might be worth a thought to do the preprocessing on the
> server. The polygon coordinates for the areas will be much less data than the
> roads itself. And on the server, preprocessing of the residental areas for
> the 4 LODs is rather cheap.

That would be nice ...if there was  a server.
I am importing either bbox-downloads from the API-server
or local/remove .osm.bz2 -files that you can select from the
download-menu. There is no place where such proprocessing
can be done.

>> I therefor require the algorithm to work with incremental updates.
>> I do have fast, indexed access to:
>> * the residential road currently being added
>> * all nodes of the road
>> * all relations the road is a part of
>> * all relations and ways and relations of the nodes
> [...]
>> 3 => merge the polygons onto one and join the 2 relations
>
> This might get expensive: as one relation would disappear, you have to update
> the entries in the node->relation index for all the nodes of the disappearing
> relation.

I do not think this would get too expensive if I use a convex polygon
to surround the residential roads. They should have few nodes.
I have no Idea how to build a bounding polygon that is not convex.
Do you?

> If you are primarly interested in drawing the areas on a map, it
> might be cheaper to keep two distinct polygons even if they are overlapping.
> Given the assumption that we never shrink polygons, there is no harm in
> forgetting that a certain node belongs to more than one residental area.

It`s an incremental algorithm.
If I never merge polygons I end up with as many polygons as there
are residential roads. If I could paint all of them there would be no point in
leaving out the residential roads in the firs place.

>> 4 => create a new polygon and a relation with all residential roads
>> contained and the surrounding polygon
>
> That also might get expensive. But I don't see any way to circumvent this
> operation.

Me too.

>> and if it is
>>   related to a surrounding landuse=residential.
>
> I would expect that this is the essential part of the algorithm: depending on
> the datastructure for the areas, it might be expensive to find the area
> something is contained in.

With "related" I mean, "be in a relation".

Detecting a surrounding human-generated poylgon should
work with an expensive getNodes(Bounds b, Selecor s) -operation. Then
we should get all residential roads inside the human-generated polygon.
This WILL be expensive if the area is large however I see no way around
this and it may be enough to fetch the first residential road returned from
the iterator returned by getNodes.

However this could break down if all residential roads are behind the
human-generated polygon in the imported map.....no idea yet.

> Assumed we are anyway in the case of few LODs, a much simpler approach might
> be appropriate: Consider the map as a bitmap of pixels, for example with the
> doubled resolution of the LOD exactness. Then one can just mark every pixel

I am not generatig bitmaps. These are vector-maps with ways that have been
filtered and simplified stored in the OsmBin -format.
Thus there are no datastructures on disk and in rendering to work with
bitmap data.
I also am concerned with the size of such a bitmap covering the
planet in e.g. 10m resolution.
I guess a vector-structure compatible with landuse=residential -polygons
is the way to go. No special-cases in rendering, no additional basic
entity-types.

PS: With OsmBin there is no quadtile-index. There is no relational database
except a local Hsqldb for indexing adresses.

Marcus




More information about the dev mailing list