Mapsui: Use NTS for Geometries - Higher Priority

[plamen-i]

@pauldendulk I know from documentation that this is on the roadmap but currently it is marked "Later".

Following recent trend in EF Core development (NTS support for spatial data types in PostgreSQL/PostGIS, SQL Server and SQLite/SpatiaLite) it clearly becomes important to switch to NTS geometries supplied by EF Core so maps can be rendered without any geometry type conversions. Can this get some higher priority given the fact that this is the last piece of full-stack online/offline .NET Core GIS application architecture (Server GDB <-> EF Core <-> WebAPI/WFS <-> Client Rendering (Mapsui) <-> Local GDB (SQLite/SpatiaLite) <-(sync)-> Server GDB) which needs some breaking changes to align geometry types with others?

[pauldendulk]

I am eager to go to NTS as well but I can only take small steps unfortunately. This is the roadmap for 2.0. I am working on the last two features right now. Not that much to go but it always takes some time to get it stable. Version 2.0 includes .NET Standard which is an important feature as well. Limiting the Viewport is also much requested.

After the 2.0 release I intend to start on the migration to NTS and going to an MIT license.

[groege]

Hey, just wanted to check in and ask if there has been any movement, it seems like 2.0 just needs some fixes and polish right? Does this mean we'll see progress on the change soon (which will as far as I understand also allow for the MIT license right?)

[groege]

Also just as information about spatialite (because I'm working on the spatialite build for Android see here: https://github.com/bricelam/mod_spatialite-NuGet/issues/6)

There are two dependencies in the spatialite project, that are LGPL as well...
While spatialite itself can be used with either GPL, LGPL or MPL, the MPL would allow to use the project as part of the app without the open source restrictions, the LGPL dependencies, if I understand correctly basically make a spatialite binary LGPL.

[pauldendulk]

@groege After Mapsui moves to NTS there is more work to be done to go MIT. It will take some time, so don't wait for that.

Could you tell me a bit more about SpatiaLite? Where can I find the work you do on SpatiaLite? How does it relate to NTS, is it an alternative or an extension? How does it relate to sqlite-net-pcl?

[groege]

It can be compiled containing sqlite or as a sqlite plugin.
If you know postgis, its basically the same functions just in sqlite
Here is a list of functions:
https://www.gaia-gis.it/spatialite-3.0.0-BETA/spatialite-sql-3.0.0.html

Hope this answers your questions :)

I was just trying to compile the existing code so it works with Xamarin on Android - though I already used the already existing make files of another project. (so basically I've just configured the build - took me 3 days just to get it working within my app)

[pauldendulk]

Is this an open source project? Where is it?

[groege]

https://www.gaia-gis.it/fossil/libspatialite/index

[FObermaier]

What is the state of this? Is there an interest in me taking this issue?

[radderz]

I think it is worth the change to go to NTS as that is the most supported framework with capabilities to do all the things spatial in .NET. Microsoft now uses this is in EFCore as the spatial library instead of the old native library that was only supported on windows. It provides a lot of tools out of the box, like importing from Shapefiles and Transformations.

[pauldendulk]

Alright, let's set this into motion. I have not started work yet. It will not be a simple port, the main work will be in making design decision, but I will try to spend some time on it. Will make a start tomorrow.

What I was thinking of is to add a new project that has a VectorLayer based on NTS. While the core Mapsui project will have no dependency on a geometry library, but will have it's own Point and BoundingBox.

Before we start I will have to decide on the current pull requests.

[radderz]

@pauldendulk I can give a hand with NTS as well as I get time, I have used the library in quite a few projects now and it is a very good library.

NTS also has it's own indexes built in, i.e. RTree indexes that enable faster lookups within a space. This could improve the performance of the renderer when it comes down to figuring out which things to draw if there are many features on the map.

I think the idea of splitting out the vector parts out from the main Mapsui is a good idea as for those that are just putting pins on a map, NTS is a bit overkill. It's only when Polygons and LineStrings etc are to be used that I think NTS would be useful instead of reinventing the wheel on all the possibly object types and the calculations.

[kubaszostak]

I would like to add some things to consider before such a big change. NTS is an API for modelling and manipulating geometries. NTS is manipulating geometry so their coordinates changing. That's why they have to use mutable classes for geometries. That's why things like LineSegment.Length, Polygon.Area or even Geometry.Envelope are recalculated on every call. They look like properties but they act like methods. I would say rather expensive methods.

On the other hand Mapsui is a visualisation library. It doesn't manipulate geometries at all. So in Mapsui could be immutable. In that scenario things like BoundingBox or Length would be calculated once during geometry initialization or using lazy property initialization pattern. If performance is important i would also go for structs over classes for storing coordinates. In c# You can't get anything faster than collection of readonly struct stored in an array.

[FObermaier]

NTS is an API for modelling and manipulating geometries. NTS is manipulating geometry so their coordinates changing.

This is not correctfor at least 2 reasons:

1. NTS also computes the relation between geometries (intersects, contains, covers) in a very sophisticated manner. The NetTopologySuite.Geometries.Prepared namespace provides __very__ fast 1:m geometry predicate checks.
2. In NTS geometries are considered being value types. While it is possible to manipulate instantiated geometries, it is not encouraged to do so. Operations like Buffer, Union, Intersection, Difference, SymDifference don't operate on input geometries.

Geometry.Envelope does not compute the envelope on every call, it just builds a new geometry based on a (possibly) pre-computed EnvelopeInternal.

How often Geometry.Area and Geometry.Length are used during visualization is not clear to me.

What is acutally needed for visualization are the actual coordinates of the geometries. These are stored and grouped in CoordinateSequences. There are implementations that are very well suitable for visualization like PackedDoubleCoordinateSequence, DotSpatialAffineCoordinateSequence or the new RawCoordinateSequence.

[charlenni]

I'm with @kubaszostak in this case. If you want to create a multi functional library, then you could use NTS. It is then ok for a small amount of geometries on the map. But if you want to have a real fast visualization library, then this is too much overhead. If you want to have a visualization library, then it could be time-consuming to create a geometry, but must be very fast to retrieve the geometry again and again each time the geometry is drawn. Is this possible with NTS?

Just my two cents.

[FObermaier]

@charlenni, I claim that using NTS geometries within MapsUI is not slower than using the currently used geometries taken from the SharpMap project.

[charlenni]

@FObermaier I think, the question is not, if we could get the same speed, but if we could get it faster. Ok not we, but for me.

The question is, in which direction MapsUI should go? Should it go into a Swiss army knife, which could display anything you want on any device you want, or should it go in the direction of a fast visualization library. For the first, NTS is the best choice. For the second one, there are perhaps better ways. I think, this should be considered first and then changes took place.

I tried to create a vector map with NTS in the background for primitives, and it was too slow. Could be, that I didn't used the correct types from NTS for that, but was, what I found.

[FObermaier]

I tried to create a vector map with NTS in the background for primitives, and it was too slow. Could be, that I didn't used the correct types from NTS for that, but was, what I found.

You have a link?

[charlenni]

Sorry, I didn't find it. Perhaps I deleted it.

But you don't have to test it. Assume you have to convert all coordinates of any geometry you use each 16 ms to the used renderer format and then create a path to draw, then you could assume, that this costs much time. And this happens each time you draw the screen, again and again.

[FObermaier]

If you implement a CoordinateSequence (and CoordinateSequenceFactory) working with arrays of SKPoints you don't have to do that.

[pauldendulk]

I am currently looking into a way in which Mapsui could support both Mapsui.Geometries and NTS. This is for two reasons:

1. The migration to NTS is a big change. It should be possible to introduce it in smaller steps with most of the functionality working for every 'Latest Build' package. Those releases should be usable for early adopters, like they are now, so that we get feedback from them.
2. I think it should be possible to render things that are not part of a geometry inheritance tree. For instance, right now we have a 'Raster' class which was derived from IGeometry, but it is not a real Geometry. It should be independent. Another such thing could perhaps be a VectorTile. This allows for performance optimization specifically for the VectorTile.

[pauldendulk]

I created a PR to prepare for NTS and wrote a proposal on how to proceed. Please give feedback everyone. Specifically those who would like to contribute like @FObermaier and @radderz.

[radderz]

@pauldendulk I have done an initial code review of the current PR which looks ok, I haven't had a chance to test it though. I'll review the proposal soon

[pauldendulk]

@pauldendulk I have done an initial code review of the current PR which looks ok, I haven't had a chance to test it though. I'll review the proposal soon

Note, there are also bigger changes proposed. Introduce a Mapsui MRect and MPoint that will be used in most interfaces. Also package rearrangement, all layers will move out of Mapsui.csproj.