On Mar 13, 2008, at 23:27, Frederik Ramm wrote:
True, but since there can only be one circumference of a polygon,
could we not specify that if more than one outer ways exist in a
multipoly relation, these will be merged to make the circumference?
That would be very confusing. I'd expect outer
Hi,
True, but since there can only be one circumference of a polygon,
could we not specify that if more than one outer ways exist in a
multipoly relation, these will be merged to make the circumference?
That would be very confusing. I'd expect outer and inner ways to be
the same kind of
Hi,
What do we do with ways that get excessively long if we combine the
polygon border? (some really big forests and lakes come to mind)
I don't know -- create a new relation type specifically for this? As
far as I can tell, the fact that putting multiple border ways in a
multipolygon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Vollmert schrieb:
Certainly the multipolygons which are just a polygon with several
ways making up the border are broken and should be fixed. I hope to
get a handle on these.
What do we do with ways that get excessively long if we
On Mar 12, 2008, at 11:47, Dirk-Lüder Kreie wrote:
Robert Vollmert schrieb:
Certainly the multipolygons which are just a polygon with several
ways making up the border are broken and should be fixed. I hope to
get a handle on these.
What do we do with ways that get excessively long if we
On Mar 10, 2008, at 22:51, Igor Brejc wrote:
I too am a little bit confused: now the whole issue basically comes
down to renaming the relation from multipolygon to
area_with_holes. But
the inital proposal had some other features, like using the inner
polygons' tags to render the inner
Hi,
If all the rings were closed and the roles where correctly defined then
there is a relatively simple algorithm to reconstruct the multipolygons
without needing too much memory or CPU overhead.
I may be a bit slow here but couldn't we then just one-by-one fix the
existing multipolygons so
Frederik Ramm wrote:
Hi,
Let's go with type=area_with_holes then, roles outer and inner as
before. All members are closed ways, the inner ways are contained
in the interior of the single outer way. The area_with_holes is the
interior of the outer way minus the interiors of the
On Mon, 2008-03-10 at 22:51 +0100, Igor Brejc wrote:
I too am a little bit confused: now the whole issue basically comes
down
to renaming the relation from multipolygon to area_with_holes. But
the inital proposal had some other features, like using the inner
polygons' tags to render the
On Mar 10, 2008, at 22:43, Jon Burgess wrote:
The original multipolygons created by the conversion above all had the
same tags and no defined roles.
Does osm2pgsql really require the same tags on all ways? The comments
in the code seem to say it's collecting tags from all member ways, in
On Mon, 2008-03-10 at 23:40 +0100, Robert Vollmert wrote:
On Mar 10, 2008, at 22:43, Jon Burgess wrote:
The original multipolygons created by the conversion above all had the
same tags and no defined roles.
Does osm2pgsql really require the same tags on all ways? The comments
in the
Ok, then please let me know when you finish this transition to the new
system, so that I can update the Kosmos code. And it would be a good
thing to include a description of a recommended logic for rendering on
the http://wiki.openstreetmap.org/index.php/Relations/Multipolygon page,
so that it
On Mar 4, 2008, at 22:10, Jon Burgess wrote:
Thanks for the information! It's becoming clear why things are the
way they are currently.
How about we define this as a new relation type and depreciate the
multipolygon type.
Which would take us right back to the beginning of the thread :).
Hi,
To map a lake in a forest area, I should currently create both a
closed way with natural=water, and a closed way that is an 'inner'
member of the forest's multipolygon relation. Both of these ways
share the same nodes (and may or may not need to be oriented in
special ways).
This seems
Hi,
The multipolygon tag is set in pgsql_out_relation for ways with
role=inner. Furthermore, pgsql_out_relation appears to aggregate tags
of all ways involved, so you should end up with
landuse=forest,natural=water on the multipolygon. I wonder what
happens when both have differing natural=
On Tue, Mar 4, 2008 at 12:06 PM, Dave Stubbs [EMAIL PROTECTED] wrote:
It's feature X that's too weakly defined. The question you're really
asking here is what is meant by forest? I think most people are
interpreting it as an area of land covered by trees, in which case a
lake is certainly
Martijn van Oosterhout schrieb:
On Tue, Mar 4, 2008 at 12:06 PM, Dave Stubbs [EMAIL PROTECTED] wrote:
It's feature X that's too weakly defined. The question you're really
asking here is what is meant by forest? I think most people are
interpreting it as an area of land covered by trees, in
As you said it yourself, a different example. As for national parks,
everything inside its borders belongs to the park. Unless it is explicitly
excluded by some inner (hole :) ) borders. Same goes with the country
borders. I think there are quite a few examples of chunks of a country A's
territory
On Tue, Mar 4, 2008 at 10:10 PM, Jon Burgess [EMAIL PROTECTED] wrote:
That is right. Looking from the outside these features may seem odd but
both were essential for the initial 0.5 multipolygon support.
The multipolygons created with the 0.5 API had no defined roles so there
was no way
Hello,
http://wiki.openstreetmap.org/index.php/Relations/Proposed/
Area_with_holes contains a proposal for an alternative to the current
multipolygon relation. Please tell me what you think about it. Am I
missing something?
In short, the proposed changes are the following:
Hello,
On Mar 3, 2008, at 18:03, Frederik Ramm wrote:
Until now I was unaware that we currently require the outer/inner ways
of polygons to be clockwise/anticlockwise. It seems that some
renderers work better if that is the case but nowhere is it a
requirement.
That's how I read
Hello,
On Mar 3, 2008, at 21:25, Jukka Rahkonen wrote:
mapnik or osmarender. From what I remember of reading the code, both
renderers skip areas with role=inner when rendering.
I can see that both renderers do draw the inner roles as holes, see:
http://www.openstreetmap.org/?
On Mar 3, 2008, at 22:29, Martijn van Oosterhout wrote:
Hmm, I thought you could use the inner natural=water as the boundary
of the forest? Does this not work?
I think not. I'm pretty sure for osmarender, but may not have had
enough patience to test out the various combinations with mapnik.
On Mar 3, 2008, at 22:45, Sven Grüner wrote:
Robert Vollmert schrieb:
I think not. I'm pretty sure for osmarender, but may not have had
enough patience to test out the various combinations with mapnik.
I was wrong about osmarender: What I remembered is actually code from
mapnik (or rather,
24 matches
Mail list logo
