Skip to content
This repository has been archived by the owner. It is now read-only.

Cycle layer misrendering multipolygons? #1656

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 18 comments
Closed

Cycle layer misrendering multipolygons? #1656

openstreetmap-trac opened this issue Jul 23, 2021 · 18 comments

Comments

@openstreetmap-trac
Copy link

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Reporter: a.t.chadwick[at]gmail.com
[Submitted to the original trac issue database at 1.51pm, Tuesday, 17th March 2009]

Example
http://www.openstreetmap.org/?mlat=51.76105&mlon=-1.26958&zoom=16&layers=00B0FTF - graveyard spilling out into the street: tags on the role:inner member are colouring the role:outer member. Will attach screenshot.

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: tom[at]compton.nu
[Added to the original trac issue at 11.13am, Wednesday, 18th March 2009]

As far as I know cycle layer issues are handled directly by Dave and Andy and not via this trac.

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: a.t.chadwick[at]gmail.com
[Added to the original trac issue at 12.21pm, Wednesday, 18th March 2009]

Fair enough. But it would be nice to have a real issue tracking system for this. Info from IRC which might be relevant

<randomjunk> achadwick: if it's a multipolygon issue on the cyclemap... then we
     know... we need a software upgrade to make this work
<randomjunk> and that software upgrade is a complete pita

I'll be patient.

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: tom[at]compton.nu
[Added to the original trac issue at 12.34pm, Wednesday, 18th March 2009]

Well ask Andy and Dave to provide one then ;-) If they want to use our trac then I'm sure we can create a component for it....

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: Andy Allan
[Added to the original trac issue at 4.07pm, Wednesday, 29th July 2009]

Not sure if this is still a problem - I'm pretty sure the software hasn't changed, but the example no longer works. Any fresh example?

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: a.t.chadwick[at]gmail.com
[Added to the original trac issue at 2.29pm, Thursday, 30th July 2009]

Looks like the inner cemetery was deleted and recreated, and the surrounding residential bit was modified to fix the rendering issue on around the 13th June 2009. They're no longer a multipolygon; sorry about that :/

Could it have been due to the outer area either a) not being imported, or b) not being rendered? Anyway, mere speculation without data; re-closing as worksforme on your behalf since I don't have any fresh examples.

Good to see that there's a component to report against now!

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: Hagebutte
[Added to the original trac issue at 5.50am, Wednesday, 2nd September 2009]

Hello,

I'm not sure whether this is a manifestation of the same problem but at least it seems related. Opencyclemap shows a number blue areas in Luxembourg which are really multipolygon forest areas, e.g.
http://www.openstreetmap.org/?lat=49.9678&lon=5.9667&zoom=13&layers=00B0FTF and
http://www.openstreetmap.org/?lat=49.8414&lon=5.9496&zoom=13&layers=00B0FTF
I have looked at the first example and modified one of the inner polygons to a counterclockwise way. If the "lake" turns into the forest with the next rendering then this may have been the cause.
It would be nice if this could be resolved.

All the best!
Hagebutte

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: Richard Mann
[Added to the original trac issue at 1.52pm, Tuesday, 29th September 2009]

Possible further example spotted (and I promise I won't fix this one, not least because it reminds me of the Hey Andy what tag do you use to get that nice pink colour for my front drive email)

http://www.openstreetmap.org/?lat=51.7516243457794&layers=00B0FTF&lon=-1.20066404342651&zoom=16

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: Richard Mann
[Added to the original trac issue at 1.54pm, Tuesday, 29th September 2009]

The pink area is a landuse=residential multipolygon. The area immediately to its north is a landuse=residential area.

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: Richard Mann
[Added to the original trac issue at 2.01pm, Tuesday, 29th September 2009]

Colour appears to have leaked out of:
http://www.openstreetmap.org/browse/way/38592559

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: grenzdebil_bonn
[Added to the original trac issue at 8.47am, Friday, 23rd October 2009]

Replying to [comment:4 Andy Allan]:

Not sure if this is still a problem - I'm pretty sure the software hasn't changed, but the example no longer works. Any fresh example?

Hi!

Pretty much every Multipolygon in this Area [1] is rendered incorrect, with the tags of inner and outer ways flipped (compare standard Mapnik and Osmarender).

Ticket [2] is another example.

[1] http://www.openstreetmap.org/?lat=50.6799&lon=6.9878&zoom=13&layers=00B0FTF
[2] http://trac.openstreetmap.org/ticket/2345

Thanks,
Martin

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: Andy Allan
[Added to the original trac issue at 12.30pm, Wednesday, 16th December 2009]

Definitely a problem with osm2pgsql's handling of multipolygons, where the tags from "inner" members get applied to the whole polygon. An update of osm2pgsql will fix this, just need to check how modern versions work in non-slim mode.

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: EvanE
[Added to the original trac issue at 12.09pm, Thursday, 25th February 2010]

Replying to [comment:11 Andy Allan]:

Definitely a problem with osm2pgsql's handling of multipolygons, where the tags from "inner" members get applied to the whole polygon. An update of osm2pgsql will fix this, just need to check how modern versions work in non-slim mode.

Is there a prospected time when you will be able to solve this problem?

For the meantime two example from the Bonn/Germany area:

  • [http://www.openstreetmap.org/?lat=50.71305&lon=7.14493&zoom=15&layers=00B0FTF Rheinaue: leisure park with lake]
  • [http://www.openstreetmap.org/?lat=50.6546&lon=7.0856&zoom=13&layers=00B0FTF Kottenforst: large forest with some small lakes inside]
@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: Ebbe73
[Added to the original trac issue at 12.37am, Thursday, 15th April 2010]

Any progress in fixing this bug?

In the Harz mountains in Germany the OpenCycleMap is currently almost useless:

http://www.openstreetmap.org/?lat=51.744&lon=10.608&zoom=11&layers=00B0FTF

In this area are many forest multipolygons: each with only one outer ring (forest) and multiple inner rings (water, wetland, scrub, etc.).

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: Andy Allan
[Added to the original trac issue at 2.05pm, Monday, 21st June 2010]

The new server is nearly ready, and has up-to-date code for multipolygon processing. It should be deployed in the next few weeks if everything goes well.

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: ToeBee
[Added to the original trac issue at 6.40am, Wednesday, 25th August 2010]

So it looks like the new server is in place but the problem persists:

http://opencyclemap.org/?zoom=12&lat=39.19272&lon=-96.52895&layers=B000

I just added the river bank multipolygons last week.

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: mtoups[at]alumni.cmu.edu
[Added to the original trac issue at 6.24pm, Wednesday, 22nd September 2010]

I have also hit this problem with riverbank multipolygons, here are a couple of other examples:

http://www.openstreetmap.org/?lat=35.91346&lon=-82.06872&zoom=16&layers=C

http://www.openstreetmap.org/?lat=29.9546&lon=-90.0509&zoom=14&layers=C

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: Richard Mann
[Added to the original trac issue at 9.49pm, Friday, 15th October 2010]

Replying to [comment:16 mtoups@]:

I have also hit this problem with riverbank multipolygons, here are a couple of other examples:

http://www.openstreetmap.org/?lat=35.91346&lon=-82.06872&zoom=16&layers=C

http://www.openstreetmap.org/?lat=29.9546&lon=-90.0509&zoom=14&layers=C

That's a separate problem (not recognising inners). I'll log a separate trac ticket for that (and mark this one as closed). But the problem of inners leaking seems to be fixed. Hurrah and thankyou!

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: mtoups[at]alumni.cmu.edu
[Added to the original trac issue at 4.38pm, Sunday, 17th October 2010]

Actually "not recognizing inners" isn't the problem I'm trying to report, either. In the second example I gave, the multipolygon relation has no inner ways, only outer: http://www.openstreetmap.org/browse/relation/534928

Yet there is still a big "flooding" problem there (on Cycle layer but not Mapnik). So while I was originally just adding this to "misrendering multipolygons", perhaps this is a distinct problem from the problems with inners? I'd open a new bug, but I'm not totally sure how to describe the problem with relation #534928 other than as a misrendered multipolygon.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant