Large shape with a 'donut' cut out areas don't render correctly.

[mottey]

HI!

I've got a WKT for Los Angeles. It's not rendering correctly with Wicket -- there's a shape cut out from the inside, and it's getting rendered.

Here's the (large) Source WKT data.

In this image we can see two areas that should be cut out.. but they are getting rendered.

And here's a good example that does render nicely, via the OpenLayers framework.

Here's some futher detailed information about this issue

[arthur-e]

Hi, thanks for your report. I have confirmed that this WKT is rendered correctly in Leaflet with the Leaflet extension (http://arthur-e.github.io/Wicket/) and in the ESRI JavaScript API extension (http://arthur-e.github.io/Wicket/sandbox-arcgis.html). I'll have to look into why this is not working for the same WKT in the Google Maps API extension, which is passing all of its tests, including Polygons with holes. However, these tests don't currently capture whether or not the google.maps.Polygon() instance looks correct when drawn.

[arthur-e]

In attempting to simplify the geometry, I found that, upon pulling it out of PostGIS, it was interpreted as a MULTIPOLYGON. That's not such a big deal, because it looks the same as the Polygon case (in the Leaflet and ESRI JavaScript API extensions). The MULTIPOLYGON with simplified geometry is located here. So, the Google Maps API extension has problems with some deep inner rings for POLYGONS and MULTIPOLYGONS.

[mottey]

Ah kewl. So you're confirming that this polygon does not render properly with the Wicket extension for Google Maps API?

[arthur-e]

It certainly seems that way; I've been able to reproduce the issue you're having.

[TraGicCode]

Is there a workaround for this arthur? the project im currently working on is really wanting to use your library, But if it cannot render the holes properly for a polygon i dont think this will work for us. Thanks

[arthur-e]

If you're not confined to the Google Maps API, you could use Leaflet or even the ESRI JavaScript API, neither of which have this problem in Wicket's extensions. Unfortunately, the Google Maps API makes it extremely difficult (impossible, as far as I can tell) to distinguish inner rings from outer rings, which is probably why this problem exists. This part of Wicket was migrated from an earlier version that used Arrays of google.maps.Marker|Polyline|Polygon instances to symbolize multi-geometries specifically because of this difficulty.

So, one fix would be for you to revert your fork of Wicket back to when it used Arrays (e.g. this changeset). You can tell by looking at the "construct" methods in wicket-gmap3.js|wicket-gmap3.src.js as to whether or not it returns Arrays for multi-geometry constructions (e.g. this line).

Otherwise, I can recommend MapBox's wellknown library which serializes WKT to GeoJSON, although Wicket does the same now in a recent update.

I'm sorry that I haven't gotten around to fixing this, but I hope I've made the case that it is a truly pernicious problem with the Google Maps API's obfuscation of inner/outer rings.

[TraGicCode]

Nah it's fine. We currently use SQL Server to store the WKT and had our company purchase the google maps API license. Unfortunately we didn't know that using WKT would be such a pain in the butt. Do you have any other recommendations besides MapBox, which i will definitely take a look at? thanks

[arthur-e]

I don't know of any other client-side (i.e. JavaScript) libraries for serializing/de-serializing WKT that don't assume what your mapping library is (e.g. OpenLayers provides native support for WKT). I would recommend you approach this on the server, using your database middleware (SQL Server API) to get your data out, WKT or otherwise, and then transform it into GeoJSON. It depends on what your server-side environment is like (e.g. Python/Ruby/Java/PHP), but there ought to be a number of libraries to choose from. Here are search results for WKT libraries in Python. See also the Python Spatial Analysis Laboratory's (PySAL) WKT writer. This article on converting WKT between VEShapes was instrumental in Wicket's own development. Also, check out the GIS Stack Exchange wkt tag for more suggestions.

[TraGicCode]

We are actually a microsoft shop so we are pretty limited to .net. But we will look around and see what we can find! Appreciate the fast response and cheers!

[PureKrome]

So @arthur-e - are you saying that we should be doing some server-side WKT->GeoJson conversion?

@TraGicCode - we're a .NET shop also so we're in the same situation as you.

[arthur-e]

@PureKrome, it's a suggestion. In my experience, sending geometry encoded as WKT to the browser is significantly less common than serializing geometry as GeoJSON/GML or even KML (not my recommendation). Wicket's initial use case was sending geometry from the client to the server, along with other parameters, via HTTP GET/POST requests. WKT was being used because it is relatively easy to read and understand, not because it is a commonly-used and popular interchange format between clients and servers (it isn't). I can see advantages for trading in WKT (it can be smaller byte-wise than GeoJSON) but if there is no client-side support (e.g. because of a bug in Wicket's Google Maps API extension) and you aren't able to roll your own solution or patch an existing one, I can't recommend anything other than to select another format (e.g. GeoJSON or GML).

I admit that I was surprised to find that the Google Maps API supports GeoJSON natively; here's an excellent tutorial about putting it on a map. If server-side WKT -> GeoJSON conversion is not an option, just combine this tutorial with wellknown or Wicket (for serializing to WKT) and you've got yourself a mapping application you can push WKT at! My Machiavellian answer should be, "I'll patch Wicket tomorrow and you can ignore GeoJSON!" but I want you to do what works best for your needs on your own timeline.

[TraGicCode]

haha! thanks alot for the info! We are planning on taking the approach recommended by you, as it seems most others do the same. Also i don't think geojson is supported natively by google maps api. Maybe i misread your thread

[PureKrome]

I was also wondering - what good C# packages (via NuGet) transform WKT to GeoJson?

[ffflabs]

Version 3.16 of Google Maps API adds a new google.maps.Data constructor, which is a collection of google.maps.Data.Geometry objects. Each of these is passed a parsed GeoJSON feature as a constructor.

There are geometric entities for each GeoJSON feature type (google.maps.Data.Polygon, google.maps.Data.MultiPolygon, google.maps.Data.MultiLinestring) and so forth, but they all extend from google.maps.Data.Geometry. I believe there's little code to patch to make Wicket capable of interacting with this structures, and we still need Wicket to persist Geometries in PostGIS-like databases.