It has been brought to my attention that my vscode-map-preview extension now produces 401 responses for stamen map tiles, which has prompted me to put out a new release of this extension to better handle this situation.
This new release updates OpenLayers to 10.2.1 and now hides stamen tile layers from the base layer switcher if you don't have a Stadia Maps API key in your extension settings as this API key is now a requirement for viewing stamen tile layers.
This impromptu update fixes up Stamen tiles support to point to the new infrastructure managed by Stadia Maps.
Since we have to do this, we've taken this migration as an opportunity to add support for many more base layer types.
The full list of base layers supported is now:
However, certain Bing and Stadia Maps layers will only be available in the base layer switcher if you provide respective API keys for these services through new configuration properties.
Don't like these base layers and want to bring your own? You can do that now too! If you have an XYZ tile set or WMTS service you want as a backdrop for your map previews, you can define such layers in your settings.json like so:
%20-%20Visual%20Studio%20Code.png)
And they shall appear in the base layer switcher as layers you can switch to
This update also refactors the viewer HTML preparation by fetching the document (to be previewed) content on viewer init instead of embedding its content into the viewer HTML. This should improve responsiveness when previewing larger files, to the point that you can make out the new preview preparation message.
However, as I started to test this with bigger and bigger files, I eventually found a limit where the VSCode APIs will not cooperate with us. This limit is the point where VSCode will either not do syntax highlighting or tokenization or both and when we try to preview such a file, it will silently fail.
For this update, we will show a better error message on such files.
%20-%20Visual%20Studio%20Code.png)
So for those who are hoping to use this extension to preview GeoJSON files whose size is in the range of gigabytes, sorry there's nothin I can do here 🤷♂️🤷♂️🤷♂️🤷♂️ I think at that point you are better served by using actual GIS tools/software for this purpose.
Now this this update is out the door, it's back to mapguide-rest development.
While I was deep into reviving mapguide-rest to make sure it works with the PHP 8.1 bundled with MapGuide Open Source 4.0, I missed the memo that Stamen Maps is now under new management: Stadia Maps.
The most important aspect of this announcement was that come October 2023 (a month from now), current stamen tile URLs may stop redirecting/working and you should have migrated over to Stadia Maps by then.
Because Stamen tiles carried the same role as OpenStreetMap as a freely accessible base tiled layer for various open source projects of mine, this announcement has thrown a spanner in my works because come next month, Stamen tiles may not work and for continued support for these layers would require migration over to Stadia Maps.
So I have momentarily suspended my work on mapguide-rest to give focus to one of my other projects affected by this announcement: My VSCode map preview extension.
Because continued support for stamen map tiles requires migrating the extension over to use Stadia Maps, we might as well take this opportunity to add support in the extension for other base layers that Stadia Maps offers. And while we're at it, we might as well go all the way and add in Bing Maps, XYZ and WMTS base layers as well.
Or, just have a gander at this clip for a taste of what the next version of the VSCode map preview extension can do!
The next version of the extension will drop real soon and then it is back to mapguide-rest development.
This update tidies up the feature popup display so that overly long name and values are now ellipsized
The original un-ellipsized content is available as a mouseover tooltip
Although I couldn't verify it, the name and content values are now also sanitized with DOMPurify to guard against any potential XSS shenanigans.
This update also includes an updated OpenLayers (6.13.0)
This minor update fixes display of spatial data that spans the international date line by turning off the flag that causes OpenLayers to auto-wrap such features
This final release of anything from me for 2020 fixes our KML content scrubbing code to no longer trash KML icon styles. OpenLayers didn't support KML icons properly when this extension was first created which necessitated scrubbing said content out when previewing KML files so that at least something will render in the preview instead of nothing.
That is no longer the case, so now KML icon styles are preserved when previewing. Case in point below, we now get cutlery icons instead of the standard pin marker.
One small caveat needs to be observed: Due to content security restrictions on the HTML generated by this extension, the KML icon URLs must be https otherwise nothing will render.
This release also updates OpenLayers to 6.5.0 and ol-layerswitcher to 3.8.3
This release updates OpenLayers to the latest 6.4.3, ol-layerswitcher to the latest 3.7.0 and adds support for opacity properties of the mapbox simple style spec for GeoJSON features.
I was originally hoping to drop the long awaited 2nd Preview of MapGuide Open Source 4.0 this week, but sadly some show-stopping bugs have crept up on the Linux side that means that sadly I have to push back the release until at least this one particular show-stopper for the PostgreSQL FDO provider is addressed.
Because this bug is present only on Linux it means we have to dive into gdb and try to debug through how this provider is producing garbage SRID values that result in broken PostGIS spatial queries.
Now normally I would dread at this prospect because gdb is command-line based and I miss being able to easily debug and step through code graphically with Visual Studio, but that was then and nowadays things are a lot different.
So this show-stopper has presented the perfect opportunity to see how hard or easy it is to tie all these pieces together for a nice debugging experience.
I start by spinning up the FDO build container and a PostgreSQL docker container to run our test code against.
Then after installing the remote extensions, I click the green box which then gives me an option to attach to a running docker container.
Which then shows the list of running docker containers, which includes my FDO build container
This then spawns up a second VSCode instance that allows me to open a folder within the running container. The FDO source code which I want to step through is accessible in this container, so I pick that folder.
Now if the experience here is the same as though I wanted to debug through this code from *outside* the container, I would then need to make sure the C++ extension is installed. I notice in this case that the extension UI shows local and remote installed extensions, so I have to install the C++ extension remotely.
If the debug experience for remote sources is the same as for local, then what should happen next is that I make a launch.json set up to run gdb with the executable that contains our test code. VSCode nicely creates a useful starting launch.json for me to tweak to what I need.
At this point, I make sure gdb is installed in the FDO build container, find some source code to stick some break points and hit the play button on the debug tab to start debugging and lo and behold ...
I am now visually debugging and stepping through the FDO source code! Just like Visual Studio on Windows. There was some small setup involved, but the process was mostly seamless.
VSCode is one truly amazing editor! With the right extensions, it can match any dedicated IDE in capabilities.
Now to tackle the actual show-stopper in question.
Posts
All Comments
