| T O P I C R E V I E W |
| Sybren |
Posted - Oct 05 2025 : 09:53:29 I noticed that under Windows 7 the TIESlippyMap doesn't connect to OpenStreetMap any more, using the 'http://[abc].tile.openstreetmap.org' provider. This is easily checked because in the ImageEn Demo section there is an app called 'GeoMaps', which won't connect as well. The provider 'http://[abc].tile.opencyclemap.org/cycle' still works but shows the nag text 'API Key Required'. The issue is easily found because the slippy map doesn't download any tile from the OpenStreetMap server, and so only shows a blue 'map' instead of the usual OSM map. It works fine under Win 10 and 11.
This may have happened recently, perhaps from Oct 1st onward, since it worked fine a week ago. Or it may be my two Win7 systems, but it's still weird that it only fails under Win7, not Win10/11.
Any suggestion how to make it work again is welcome.
Thanks, Sybren |
| 9 L A T E S T R E P L I E S (Newest First) |
| xequte |
Posted - Oct 26 2025 : 19:20:20 Hy Sybren
Well you could create a TImageEnIO helper method to do it. We couldn't do it at our end as it would add an Indy dependency.
Nigel Xequte Software www.imageen.com
|
| Sybren |
Posted - Oct 26 2025 : 03:28:59 Hi Nigel, Thanks for your quick response.
I've tried to download any tile from OSM using a different approach. This works well:
uses IdHTTP, IdSSL, IdSSLOpenSSL;
{ and include libeay32.dll and ssleay32.dll to the .exe directory }
procedure TForm1.GetURLImage(sURL: string);
var
ImageEnView1: TImageEnView;
MS: TMemoryStream;
begin
ImageEnView1 := TImageEnView.Create(nil);
MS := TMemoryStream.Create;
try
MS := DownloadImageFromURL(sURL);
ImageEnView1.IO.LoadFromStream(MS);
// then do whatever is needed with ImageEnView1
finally
MS.Free;
ImageEnView1.Free;
end;
end;
function TForm1.DownloadImageFromURL(sURL: string): TMemoryStream;
var
ImgHTTP: TIdHTTP;
SSLHandler: TIdSSLIOHandlerSocketOpenSSL;
begin
Result := TMemoryStream.Create;
try
ImgHTTP := TIdHTTP.Create(nil);
try
SSLHandler := TIdSSLIOHandlerSocketOpenSSL.Create(ImgHTTP);
SSLHandler.SSLOptions.SSLVersions := [sslvTLSv1_1, sslvTLSv1_2];
// alternatively: SSLHandler.SSLOptions.SSLVersions := [sslvSSLv23];
ImgHTTP.IOHandler := SSLHandler;
ImgHTTP.HTTPOptions := ImgHTTP.HTTPOptions + [hoNoProtocolErrorException];
ImgHTTP.Get(sURL, Result);
Result.Position := 0;
finally
ImgHTTP.Free;
end;
except
Result.Free;
end;
end; I will now use these two procedures to download the tiles, using the tile zoom and x/y indexes. However, it would be better to inject/replace the above procedure in the .IO. code itself, e.g. by adding an overload procedure of LoadImageFromURL. Can you perhaps indicate where this would fit the best?
Again, thanks for your support,
Sybren |
| xequte |
Posted - Oct 25 2025 : 17:44:46 Hi Sybren
Sorry, I'm not really sure what to suggest here other than stepping into the ImageEn LoadFromURL() code and seeing if you can spot anything unexpected. However, I expect you will find the issue occurs within the Windows API calls.
Nigel Xequte Software www.imageen.com
|
| Sybren |
Posted - Oct 25 2025 : 16:17:06 Thanks Nigel,
I've studied the suggested code from your response and tested it in a simple app: - putting 3 ImageEnView components and 3 Buttons to a Form - each button downloads an image using .LoadFromURL showing in the assigned ImageEnView.
First button downloads openstreet cycle map: 'https://tile.opencyclemap.org/cycle/6/15/17.png'. Second button downloads openstreet map: 'https://tile.openstreetmap.org/6/14/17.png'. Third button downloads a free image: 'https://upload.wikimedia.org/wikipedia/commons/5/52/Free_logo.svg'. As a result the first and third images are downloaded. Changing to .LoadFromFileAuto gave the same result. Meaning: both .LoadFromURL and .LoadFromFileAuto work well.
However, when I download these images in my browser, they all show. Now this is weird, because apparently my Win7 system is correctly configured to exchange requests with the OpenStreetMap servers, while in my test app the cycle map gets response and the 'normal' map doesn't. The only way I can explain this is that the protocol between .LoadFromURL is not working because the OSM requests something that .LoadFromURL does not deliver (or vice versa), due to a recent change of protocol from OSM. And I have no clue what that may be.
I hope that anyone can share some light on my issue. I know, Win7 is a dinosaur and unsafe system, but it's a perfect environment for app development because it's not updated every week and behaves less paranoid ;-) FWIW: I'm using Rio 10.3 (Win7) and Athens 12.2 (Win11) as development environments.
Thanks anyway to take time to respond to my call for help!
Sybren |
| xequte |
Posted - Oct 13 2025 : 01:31:51 Hi Sybren
Unfortunately I cannot see anything obvious about why it should fail under Windows 7, and because we don't have any Windows 7 machines I cannot debug it.
Slippy map downloading is handled by TImageEnIO.LoadFromURL:
https://www.imageen.com/help/TImageEnIO.LoadFromURL.html
Which calls Windows internet API methods, so presumably there is some issue there.
You might want to step into the ImageEn code yourself to see what is going on, e.g. by just loading a tile directly:
ImageEnView1.IO.LoadFromURL( 'http://a.tile.openstreetmap.org/4/6/7.png' );
Nigel Xequte Software www.imageen.com
|
| Sybren |
Posted - Oct 07 2025 : 02:51:09 Thanks Nigel, appreciate your time to dig into this.
I've tried to understand where the actual download of the OSM tiles takes place (iexVirtualBitmaps.pas) but it eludes me how and when the slippy map component downloads the actual map tile. I found a download queue (TList) and a 'ProcessQueue()' command but that's all...
To test if the executable itself is somehow not compiled properly, I copied the GeoMaps.exe generated under Win11 onto the Win7 system. Same issue: not downloading the tiles. This should exclude any compiler directives as a possible cause.
If you test other than Win7 you may not experience this issue. Perhaps a Virtual Machine can help you here (Win7 should still be out there, despite not being activated any more by Microsoft)? You only need a working Win7 to test the GeoMaps.exe to see if this is a generic Win7 problem, or it's somehow related to my two Win7 systems.
Lastly, I disabled the firewall and similar features, just to make sure the app is properly connected to the outside world. As expected: it was properly allowed, so no reason to suspect the firewall as the culprit.
Again, thank you for your support, And I upgraded to 14.0.0. Indeed the changes were minimal!
Thanks,
Sybren |
| xequte |
Posted - Oct 06 2025 : 15:38:47 Hi Sybren
I'll need to investigate potential reasons for this (although I no longer have a Windows 7 machine for testing).
I can't see any reason that v14.0.0 will improve this issue. The upgrade should be painless though, only need to rename hyieutils and hyiedefs in your uses clause, but we have an app to do that automatically:
http://www.imageen.com/help/Compatibility.html
Nigel Xequte Software www.imageen.com
|
| Sybren |
Posted - Oct 06 2025 : 14:34:17 Thanks Nigel for quick response.
I tested the GeoMaps as-is, so ImageEnView as the map visualization. In Win10/11 it will correctly download images from OSM into the cache folder. In Win7 I can also download the individual images in my browsers (Firefox and Chrome, I'm not using IE any more), when I paste the link to such an image (e.g. https://tile.openstreetmap.org/8/139/88.png, please note the 's' in https).
I can still programmatically download these OSM maps images to e.g. the cache folder, using instances of TIdHTTP, TIdSSLIOHandlerSocketOpenSSL and TFileStream. But that's not a real solution. I'm using version 13.7.0. Should I switch over to 14.0.0? I hesitated because of the many unit adaptations I had to make.
Interestingly, when tiles are still available in the cache, it will read these when initiating the slippy map. To test, I executed the GeoMaps on a Win11 system, then copied the cache folder content to my Win7 system, and restarted GeoMaps in Win7. It now shows the map correctly, But by zooming or panning outside the cache area, it won't add new tiles to the map.
Hope this helps a bit. Thanks for your support, Sybren |
| xequte |
Posted - Oct 06 2025 : 08:18:10 Hi Sybren
Did you test it in a web browser, particular Edge or Internet Explorer?
I'll investigate further when I'm back in the office next week.
Nigel Xequte Software www.imageen.com
|
|
|