Yes, I see that problem too.
I think it's because we're not applying buffering to the MVT tile encoder,
so client applications are falsely led to believe that they are legit
separate features and not a single feature that crosses multiple tile
boundaries.
- Jackie
--
Sent from:
Hi Jackie,
at least I can now see features on the map. But I think there are two more
issues:
1. When rendering the features in the client application (OpenLayers, QGIS)
the borders of the tiles are rendered, too. It's hard to see with the
Sheboygan dataset. But when you decrease the "Min scale"
Hi Gunter,
The issue appears to be that current OpenLayers is expecting extra MVT
metadata that the MVT encoder is not encoding in (namely the default extent
of 4096). This screws up the resulting OL feature coordinate computation
(that is expecting this extent value to be there), rendering all
Hi Jackie,
I've got one more finding while debugging a Mapbox-Service, that let me to
the conclusion that the issue is propably MapGuide related:
In OpenLayers up to v4.3.4 all features that were loaded by either
Mapbox-Service or MapGuide-Service have tile coordinates between 0 and 4096
Hi Jackie,
thanks for your reply. I already checked all the release notes up to the
current version and have made the relevant changes. I had now time to look a
little closer into this problem and figured out, that there is an issue with
the coordinates of the geometry and not the styling what
Hi Gunter,
Thank you for pointing out to my attention that the non-OL2 samples still
bundle OpenLayers 4.1 so I would not be surprised that the samples don't
work 1:1 when ported to the latest OpenLayers.
I'll eventually fix up the samples to use the latest OpenLayers as part of:
