0

I'm having an issue with Multipolygons on CartoDB.

I have a very simple scenario: A multi polygon row on a table that needs to be displayed on the map. Fact is that when more than two polygons somehow colide, the MapView only display the portions that are not common between the polygons. It's very simple to demonstrate:

those are the original 3 polygons, manually rendered using Google Maps API

(Those are the original 3 polygons, manually rendered using Google Maps API)

this is the CartoDB rendering. The overlapping area is missing!

(This is the CartoDB rendering. The overlapping area is missing!)

The craziest thing is that the renderer shows the portion covered by the three polygons. You can see the small area of Botafogo, this area is covered by the three polygons and is correctly shown on the CartoDB rendering.

Any idea why this is happening and how to fix it? I couldn't find anything useful on the documentation. The only workaround I could come up with is by doing some operations using Postgis (ST_Polygonize) but if I do this I'll lose the filtering options, since I'll be using a custom query. Also, to me, it makes no sense why CartoDB is not showing the overlapping area.

3
  • Could you share the WKB or WKT of your polygon. To get it use "select st_astext(the_geom) from table where cartodb_id = XX". It would be helpful to see how you render that multipolygon using google maps Commented Nov 27, 2014 at 8:23
  • Hello @javisantana, here is the WKT: pastebin.com/eYnC03c4 I'll upload the tool I created to plot the polygons on google maps to Github.IO and come up with the link in a few minutes. Commented Nov 27, 2014 at 17:03
  • Here is the tool to plot polygons on GMaps: rtodorov.github.io/gmaps_polygons.html Basically I'm adding 3 polygons instead of one multi polygon: pastebin.com/pvPgWPbd Commented Nov 27, 2014 at 17:36

1 Answer 1

0

In your case the last polygon has a reversed order in the vertices so that's why mapnik (the library we use for rendering) the geometry is removed.

If you reserse the order for the latest polygon (with st_reverse for example) it's rendered as you expect. I don't actally know if that's expected and it's a mapnik bug, I'd recommend you to file a ticket in its repo.

This is the "fixed" polygon:

MULTIPOLYGON(((-43.162879943848 -22.913021404896,-43.183307647705 -22.891041392518,-43.209915161133 -22.897841345212,-43.209915161132 -22.909068428006,-43.21626663208 -22.92092701284,-43.220729827881 -22.93310074698,-43.196353912354 -22.940372845276,-43.187084197998 -22.953493251659,-43.168888092041 -22.953809390333,-43.148288726807 -22.921875654802,-43.162879943848 -22.913021404896)),((-43.142280578613 -22.966296276961,-43.175239562988 -22.944482988916,-43.207511901855 -22.941953684522,-43.233604431152 -22.9495414559,-43.246307373047 -22.98115258902,-43.262100219727 -22.984313295763,-43.264846801758 -22.965031834579,-43.293685913086 -22.963767380373,-43.29231262207 -23.004224047371,-43.215408325195 -22.988422103968,-43.189830780029 -22.991266590272,-43.142280578613 -22.966296276961)),((-43.220901489258 -22.922349973292,-43.221416473389 -22.93626257684,-43.305015563965 -22.995059145473,-43.243560791016 -22.999799689663,-43.122024536133 -22.947960705279,-43.164596557617 -22.9043247036,-43.198757171631 -22.903692194474,-43.213176727295 -22.912072700955,-43.220901489258 -22.922349973292)))
3
  • Hey @javisantana, thank you very much for your reply. It sounds like a bug to me because in my opinion the vertices order shouldn't matter, right? If I'm wrong, please let me know so I can understand it better. Also, as a workaround, is there a way for me to know if I should apply st_reverse on a polygon or not? How do I find if the polygon is reversed or not? Thank you very much for your attention, I'll file a ticket on the repo anyway. Commented Dec 2, 2014 at 13:21
  • the circular order is important because the rendering API use that order to know if they need to render the polygon or subtract the polygon depending if the polygon is CW or CWW. What I'm not sure if that order should take effect for different polygons in a multipolygon. Take a look at this thread to see an explanation of this: github.com/openlayers/ol3/issues/803 Commented Dec 3, 2014 at 7:20
  • makes sense, so the vertices order does matter, of course. I would have known this if I've studied a bit about polygons and its rings before I started this thread. Anyways, I solved the issue by pre-processing the data, joining the polygons using the Union method from GEOS before exporting my data to CartoDB. This solution fits better to my needs because now I have only one polygon per row, which gives me a clearer map. Commented Dec 3, 2014 at 13:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.