ThinkGeo.com    |     Documentation    |     Premium Support

Classic renderer and data sources: five small gaps

#1

We use ThinkGeo.Core / UI.Wpf 15.0.0-beta154 in a WPF desktop GIS. These are gaps in the classic (CPU) renderer and the data readers. We have a workaround for each, but they cost us code we would rather not keep.

1. Shapefiles with Z get no labels A shapefile of type PolygonZ, PolyLineZ, PointZ or MultiPointZ draws fine, but never shows a label. The shape keeps its Z flag, and the label placement then produces nothing, at every zoom level. The vertices are plain X/Y anyway. Our workaround: a ShapeFileFeatureSource subclass rebuilds every drawn feature as a 2D shape. Ask: label placement should ignore Z.

2. WFS 2.0: geometry missing from GetFeature, and namespace needed for BBOX With some services (German ATKIS) the PROPERTYNAME list the SDK sends to GetFeature leaves out the geometry, because the geometry is inherited and the SDK reads the GML reference as a normal property. The service then returns features without positions. The same services also reject a BBOX filter unless the request carries a NAMESPACES=xmlns(prefix,uri) parameter for the feature type. Our workaround: a WfsV2AsyncLayer subclass removes PROPERTYNAME from GET requests and adds the namespace binding, which it reads from the capabilities. Ask: keep the geometry in the property list, and add the namespace binding when the type name has a prefix.

3. WFS: no way to learn the geometry type of a feature type We need to know whether a WFS type is points, lines or polygons before we style it. The SDK does not expose it. Our workaround: we wrap the HTTP response and read the GML element names as they stream past. Ask: expose the geometry type from DescribeFeatureType , for example a property on WfsV2AsyncLayer or its feature source.

4. WMS: advertised scale ranges are ignored Services declare MinScaleDenominator / MaxScaleDenominator (or ScaleHint ). WmsOverlay does not read them, so outside that range the map requests tiles and gets blank images. Our workaround: we parse the capabilities XML ourselves and show the range to the user. Ask: expose the advertised ranges on WmsOverlay (per layer), and ideally skip requests outside them.

5. LayerOverlay.TileCache cannot be swapped while drawing The overlay reads TileCache again after every tile it draws. If we replace the cache while a draw is running, some tiles go to the old cache and some to the new one. Our workaround: an overlay subclass that gates and cancels every draw around a cache change. Ask: either read the cache once per draw, or offer a safe way to rotate it.

#2

Regarding 4) - we have some services which display content on ranges outside the advertised scale range. Can you somehow recognize that, or are we limited to the advertised range?

#3

Hi Julian,

All five are in beta160.

  1. Z shapefiles. Fixed, but it is not what you described: PolygonZ and PolyLineZ label fine here on both beta154 and beta160. PointZ was the broken one, and it lost the whole feature, not the label — the index query simplified its only point away. PointZ, PointM and the three Multipoint types are excluded from that now, as Point already was. If a PolygonZ file of yours still loses labels on beta160, please send it over.
  2. WFS geometry and BBOX. The geometry is found by resolving the namespace instead of looking for “gml” in the prefix, so ns2: services keep their shapes. A prefixed TYPENAME now carries NAMESPACES=xmlns(prefix,uri).
  3. WFS geometry type. New WfsAsyncLayer.GeometryType / WfsAsyncFeatureSource.GeometryType. A property, valid after OpenAsync, no extra request.
  4. WMS scale ranges. WmsServerLayer.MinScale / MaxScale are filled now, from 1.3.0’s denominators or 1.1.1’s ScaleHint. To your follow-up: we report the range, we do not enforce it — services do serve outside what they advertise, so that call is yours.
  5. TileCache. A draw takes one snapshot of it, so a cache set mid-draw applies from the next one and never splits a pass.

Thanks,
Ben

1 Like