.NET Standard support

[pauldendulk]

Thanks for you library!

I like how this can be used in other mapping library. I was thinking to add it as a TileSource in BruTile. If it support .NET Standard it could be used on all the platforms BruTile supports. Looking at the code I would say there is not that much standing in the way. There is a WritableBitmap that could be replaced by other methods to render to bitmap. What is the reason it does not support PCL or .NET Standard right now? Any specific limitations you ran into or did you just not attempt to?

[charlenni]

The library uses file io, which is desktop dependent.

[AliFlux]

I don't think there's any specific core code that is desktop dependent. The file i/o methods are mostly just helper functions (except for loading mbtiles from file, using sqlite). I took the desktop approach because at the time of development, I didn't have the .net standard/core framework 😆

[pauldendulk]

I looked into this but need to do some cleanup first to know what is actually needed. I created a PR to remove the binaries. I also see alot of unused references.

[AliFlux]

Hi guys.

I've made a Mapbox GL JS port for .Net. Check out my newest project:
https://github.com/AliFlux/MapboxNet/

I wanted to create a pure C# vector map, but it was too complicated and I was juggling a few projects already. So I ended up porting Mapbox GL JS using CefSharp and it works awesome!

[rbrundritt]

Interesting. I've been working on something similar for Azure Maps. The one issue I have with cefsharp is that the winform version works great but you can't display xml elements above it which many will want to do in WPF for things like pop-ups. The WPF version of cefsharp isn't as performant and doesn(t support touch well, but xaml can be overlaid above it. What I'm considering doing is exposing an option where the user chooses if they want to allow xaml to be overlaid and then switch between the different cefsharp versions. Not sure how well the two versions run side by side but will find out soon.

[AliFlux]

I faced the same issue while developing this library. I initially used Microsoft Toolkit, which is basically a WebView that is based on Edge engine. Halfway through I realized that they have a ton of security restrictions and won't allow their webview to communicate with localhost :/ It was pretty performant though.

We can allow the user to chose whether they want to use an overlaid version (WinForms in WinFormsHost) or pure WPF, but that would require a System.Windows.Forms reference, and it's kinda deal breaker for some people.

MapboxNet WPF version is a bit faster than just running mapbox in CefSharp in WPF. The parameters have been tuned.

[rbrundritt]

I looked at the Microsoft toolkit as well but thought the xaml islands would limit the library to windows 10. Looked at the tuning you did for cefsharp and I've been doing the same. Haven't had any customers mention any issues with system.windows in the past, but could create two seperate libraries with shared code fairly easily so that the choice is made at the package level. Get Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: Ali Ashraf <notifications@github.com> Sent: Friday, April 26, 2019 7:46:27 PM To: AliFlux/VectorTileRenderer Cc: Ricky Brundritt; Comment Subject: Re: [AliFlux/VectorTileRenderer] .NET Standard support (#2) I faced the same issue while developing this library. I initially used Microsoft Toolkit, which is basically a WebView that is based on Edge engine. Halfway through I realized that they have a ton of security restrictions and won't allow their webview to communicate with localhost :/ It was pretty performant though. We can allow the user to chose whether they want to use an overlaid version (WinForms in WinFormsHost) or pure WPF, but that would require a System.Windows.Forms reference, and it's kinda deal breaker for some people. MapboxNet WPF version is a bit faster than just running mapbox in CefSharp in WPF. The parameters have been tuned. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAliFlux%2FVectorTileRenderer%2Fissues%2F2%23issuecomment-487248410&data=02%7C01%7C%7C719d62594ebe48dabf8a08d6caba8bfe%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636919299888791117&sdata=3L5rE3vizxutHx40ckfBaHCY4X%2BuFHiIM1OgYO62N3I%3D&reserved=0>, or mute the thread<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABRJCRHDOYNUBOEFANJWMFTPSO5AHANCNFSM4E3DYWJA&data=02%7C01%7C%7C719d62594ebe48dabf8a08d6caba8bfe%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636919299888801128&sdata=5WpkzYDzg9iwt%2BXupVBeQBvG7gJY1vylSRH5gzkMZQA%3D&reserved=0>.

[AliFlux]

Some devs don't like references to System.Windows.Forms when they're working with WPF. For that reason I've made two different projects, one for WPF, other for WinForms.

I'm thinking about making a third project as well. A WPF version that uses WinFormsHost for CefSharp control. That way we'll have more control over the binding, since the MapboxNet WinForms version doesn't have dependency properties. There will be an issue of overlay but I guess it can be solved using <Popup/>.

[ststeiger]

The use of WPF (System.Windows.Media.BitmapSource) does make it Windows-dependant, and therefore non-NetStandard.
There are only a few changes required to make it netstandard, I've done it, see:
https://github.com/ststeiger/VectorTileRenderer

[AliFlux]

@ststeiger you have done some nice upgrades. Can you send a merge request so that i can test and upgrade this repo

[memsom]

I have a version that is completely not dependent on any Windows specific frameworks. Basically, it uses pure SkiaSharp. I don't know how ready it is for merging, but I made it mainly for my own usage.

The main things I had to do:

• remove all the colour stuff - this was tied to WPF. It now uses SKColor for all the colours, with a nod to System.Drawing.Color in a couple of places.
• remove all the Bitmap related functions. It now uses byte[] and SkiaSharp's rendering directly to handle PNG loading and generation.
• removed any dependency on Point, Rect, Size and Vector - so at the moment we are using my own classes for this, but I'll look at using the Skia ones (though they all use float, soo I guess will lose precision.) I will probably just carry on using my own, but will probably break them out in to a new assembly.
• pulled in the HSL routine from ColourSpace, though I think SkiaSharp can handle HSL natively, so I will probably factor that out. I went through a lot of pain getting the colours to render correctly because of the magic numbers needed to create to correct HSL values.
• embedded the Clipper in to the code because there was no viable .NetStandard version. I also needed to mess about with it to make it work as the latest version available is not compatible with the released nuget that was originally used (there was no AddPolygon(..) method for example.)
• embedded the latest MapBox libs, as there was no version in Nuget that was recent and .NetStandard.
• upgraded the codebase to use .Net4.8 for the WPF demo and .NetStandard2.0 for the lib. This also involved me updating all the deps to newer versions, so we are now targeting Mapsui 3.02 and BruTile 4.0.
• Broke up large files and removed inlined enums/classes as they are more ugly to work with,

I also made all the nonstandard method naming to be in line with standards (so no Camel case, all is now Pascal case.) The main library now only depends on SkiaSharp for all drawing.

Next plan:

• embed the resources (styles and fonts) so that they do not need to be deployed with the assembly. Hopefully use them directly from the resource, otherwise I guess they will be written to a local directory when the app starts(?) This will make use on Mobile a lot easier as the assembly won't need to put files in to odd places so that the Android/iOS app can locate them, and will not need a user to know about any of that.
• make the styles fixed, so that I can create an enum to represent them, but allow for a custom one to be specified. I don't think it needs to be more complicated than that. Most use cases I have needs a regular, dark and light option.
• add in a better scheme for caching tiles. I think it will probably be by number - it will cache the last N tiles, and the cache will be like a circular buffer. Not ideal, but unless a user zooms in and out a lot and moves around on the map a massive amount, it should be fine. I think we'd allow the cache size to be set externally anyway.
• possibly create an option to generate a cache in an mbtiles database. This would then be used on the desktop to generate raster MBTiles databases for offline use. Our current solution involves setting up an entire database for a PBF from OSM or one of the other providers that slice the data like GeoFabrik, and then use QGis to generate an mbtiles file for offline use. I creating an app that will allow them to generate tiles for specific zoom levels and a specific area or areas is going to be a lot more pleasant for users to interface to.

Feel free to take a look. I intend to keep my fork up to date with your changes as far as I can. I will also offer you back any changes I make.

https://github.com/memsom/VectorTileRenderer

Edit: the biggest changes are in the XamarinForms branch. I think Master is still using 4.6.2