Hi
In the printer overlay, after I added the ScaleLine, I noticed that as I adjusted the position of certain elements and zoomed in and out of the content, the text within the ScaleLine became progressively smaller. At times, when the map was rendered, the ScaleLine displayed no text at all.
Please let me know if you need a sample project; I assume this is very easy to replicate.
Best wishes
Mahdi
hi @Mahdi_Rastegari,
Thank for your feedback. The issue has been fixed already. Could you please upgrade to ThinkGeo.Core 14.3.0-beta089 and give it a try?
Regards,
Leo
Hi
I tried version beta089, and it seems there are some other bugs in the background map. Also, there are some changes in AsyncWmsLayer that made our build fail. Just one question: When do you think we can have a stable release?
Best wishes
Mahdi
hi @Mahdi_Rastegari,
Could you kindly share any specific bugs you’re encountering? Additionally, it would be helpful to know what changes might have caused the build to fail. This will allow me to assist you more effectively.
Regards,
Leo
Hi Leo,
I’m encountering a build error related to BingMapsAsyncLayer and OpenStreetMapAsyncLayer . These layers used to inherit from WebBasedAsyncLayer , but now their contract has changed so they inherit from WebRasterXyzTileAsyncLayer . In contrast, GoogleMapsAsyncLayer still inherits from WebBasedAsyncLayer .
I also noticed that the bug we fixed in beta086 has reappeared in beta091 (as discussed here). The error occurs when LegendAdornmentLayer.Title is set to null, resulting in the following stack trace:
System.NullReferenceException: Object reference not set to an instance of an object.
at ThinkGeo.Core.LegendAdornmentLayer.GetWidthCore()
at ThinkGeo.Core.LegendPrinterLayer..ctor(LegendAdornmentLayer legendAdormentLayer)
Since this package is part of our end product, every update forces us to spend about a day checking every aspect of our product, and then the product team needs an additional week for thorough testing.
Best wishes,
Mahdi
Hi Mahdi,
Yes, we changed the hierarchy of BingMapsAsyncLayer and OpenStreetMapAsyncLayer, their inheritance hierarchy is different but they should keep the same APIs and features.
Here is the new class Hierarchy for OpenStreetMapAsyncLayer, (it’s the same for BingMapsAsyncLayer):
LayerBase -> AsyncLayer -> XyzTilesAsyncLayer -> RasterXyzTileAsyncLayer ->WebRasterXyzTileAsyncLayer -> OpenStreetMapAsyncLayer
GoogleMapsAsyncLayer still inherits from WebBasedAsyncLayer because google map request is not tile based.
LayerBase -> AsyncLayer ->WebBasedAsyncLayer->GoogleMapsAsyncLayer
We made this change to unify the reprojection/caching for all the XYZ based layers and greatly simplify the code. We had an XYZ Based Layers section in HowDoI to show it.
The LegendAdornmentLayer.Title == null issue should have been fixed in the latest beta93.
Sorry we don’t have a chance to test through the beta versions, the best way is to wait for the stable version (we are aiming for April) but if the timing doesn’t work, let me know when you guys targeting at your release and we can slow down adding new features and focus more on bug fixes during that time.
We are working on the other issues you asked.
Thanks,
Ben
Hi Ben,
Thank you for your message and for fixing the Legend bug—I really appreciate it!
Could you please explain the differences between Bing and Google that led you to decide they should have different hierarchical inheritance?
Best regards,
Mahdi
Hi Mahdi,
BingMap and OpenStreetMaps are based on XYZ tiling system, we locate tiles based on their Z-X-Y and stitch them together on the client. Here below gives you a quick idea:
However instead of Z-X-Y, Google Map Static API (the service we are using) is using center+zoom+width+height to locate a tile, and Google doesn’t allow the client to stitch the tiles. For regular users Google returns up to 640x640 tiles, for premium users Google returns up to 2048x2048 tiles. Please check out the detail below.
Get Started | Maps Static API | Google for Developers
That’s why ThinkGeo’s GoogleOverlay only supports single-tile and returns up to 640x640 (2048x2048 if you are using premium Google API Key) even the map canvas is bigger than that. If you add a GoogleMapAsyncLayer to a multi-tile LayerOverlay, even it stiches the tiles together, that’s not allowed by Google license and practically not useable as there will be a google logo on each of the returned tile .
I hope that makes sense, let me know if you have any questions.
Thanks,
Ben
Hi Ben,
Thank you for your helpful explanation. It clarified a lot, but I still have some confusion regarding why XyzTilesAsyncLayer is not inherited from WebBasedAsyncLayer . It seems that both layers call external APIs, which would suggest some similarity. However, I understand this might be due to software architecture decisions.
Anyway, I appreciate you taking the time to work on this ticket.
Best wishes, Mahdi
Hi Mahdi,
It’s because not all the XyzTilesAsyncLayers are web based. For example a local Raster MbTiles file is also based on XYZ. If you are familiar with QGIS, you can create a local XYZ mbtiles / local XYZ tiles in directory from the loaded map (see below). Those formats follows the same XYZ structure just like BingMaps or OpenStreetMaps.
FYI: ThinkGeo HowDoI also shows how to display those offline XYZ formats.
We have interface IHttpRequestService which has all the web related properties/methods, and the following classes both implement it
WebBasedAsyncLayer : AsyncLayer, IHttpRequestService
WebRasterXyzTileAsyncLayer : RasterXyzTileAsyncLayer, IHttpRequestService
Thanks,
Ben
