Mapsui 4.0 roadmap

[pauldendulk]

Considering the roadmap voor Mapsui 4.0.

Some options:

• Use NTS
• Migrate to MIT (Use NTS and other changes)
• Improve performance. Measure performance. Transform to SkiaSharp objects when fetching data.
• VectorTile support (could be through library).
• World Wrap World Wrap #518

It is possible to vote with a thumbs up on feature-request issues:
https://github.com/Mapsui/Mapsui/issues?q=is%3Aopen+label%3Aenhancement+sort%3Areactions-%2B1-desc

I move some of the feature request issues to a backlog repo https://github.com/Mapsui/backlog/issues (not sure if that was a good idea).

[pauldendulk]

Replacing the Mapsui geometries is a pre-requisite for going to MIT. Options:

• Use NTS
• Create something simple ourselves.

NTS might have some additional benefits

• Projections: https://github.com/NetTopologySuite/ProjNet4GeoAPI
• Shapefile support: https://github.com/NetTopologySuite/NetTopologySuite.IO.ShapeFile
• VectorTile writer: NTS vector tile IO NetTopologySuite/NetTopologySuite#379

[charlenni]

I used NTS for the vector tiles, but found, that it is slow. Could be, because I created 10.000 and more geometries.

There are only few geometries: point, line, polygon. Are there any other?

[radderz]

• It would be nice to have a world wrapping system for the map, i.e. so that we can scroll left for instance infinitely and have the map wrap back on itself.

I have implemented this myself in a pretty hacky way, but this is the way that all other flattened world map systems work like google maps, here maps, osm etc.

I like the idea of supporting NTS, it is a great library and would enable the stripping of a fair bit of code from this project.

I use NTS a lot and have found it a good library.

[pauldendulk]

@charlenni That is worrying. I was thinking of making the core less dependent on geometries. This becomes possible by using the rendering callback for everything. This way we do not have to know the type of the geometry in the Renderer class. Implementations of the callback could use whatever they want. For locations and boundingbox I would like to use our own custom types.

There will still be operations on geometries like projections and such, but they could be inside layers and providers.

Not sure how far we can get with this approach, have to try this in code. So perhaps a geometry type could be a vectortile and the core of Mapsui should never have to know that it is.

[pauldendulk]

@radderz ah, a logical suggestion. Something that we Europeans do't see as much a problem. Still I don't think it should have the highest priority right now. I think it is a nasty feature to implement which could have a lot of edge cases that pop up later on. For instance, how would it work with the limiter. What kind of things did you run into?

Vote here for this feature: #518

[pauldendulk]

@charlenni btw, about NTS not supporting many geometry type. What kind of types do you expect? I think NTS follows the simple features which is a very particular set of geometries, it has, for instance, no circle. But I am not even sure if NTS supports all the other types specified here.

[charlenni]

No, I don't say, that NTS isn't supporting many types. I say, that Mapsui doesn't need many types. NTS is a very good library to do all you can imagine, but is this, what Mapsui needs? One of your goals is, to make Mapsui faster. I don't think, that we can reach this goal, if we use such a heavy library like NTS. So the question is, what could NTS provide for Mapsui, that Mapsui needs?

When I see, how long 2.0 needed, than I would say, that we should make a roadmap for 2.1, 2.5 and 3.0.

[radderz]

@radderz ah, a logical suggestion. Something that we Europeans do't see as much a problem. Still I don't think it should have the highest priority right now. I think it is a nasty feature to implement which could have a lot of edge cases that pop up later on. For instance, how would it work with the limiter. What kind of things did you run into?

Vote here for this feature: #518

I basically hacked the globalmercator projection to be 7 times as wide and as it escapes the >1 world past the center I wrapped back in -1 world without any form of animation, you can't see it. Performance is fine, but it makes it a little trickier when trying to do navigations using animations and you have to have duplicate features if you allow the user to zoom far enough to see >1 full world width. overall works reasonably well even with a large number of features though.

I have customers with assets in multiple continents so it's a bit weird if I don't enable some form of wrapping. I looked into doing it a bit cleaner, with having the tile fetcher aware of it and the feature drawing side of things also aware of it so I don't need duplicates with a hack but never got around to completing it.

[radderz]

No, I don't say, that NTS isn't supporting many types. I say, that Mapsui doesn't need many types. NTS is a very good library to do all you can imagine, but is this, what Mapsui needs? One of your goals is, to make Mapsui faster. I don't think, that we can reach this goal, if we use such a heavy library like NTS. So the question is, what could NTS provide for Mapsui, that Mapsui needs?

When I see, how long 2.0 needed, than I would say, that we should make a roadmap for 2.1, 2.5 and 3.0.

I have >4000 SVG icons with touch in a small space for things around airports on my app and am using NTS for the under the hood stuff, so would cause me less pain to have mapsui to use it so I don't have to do so many conversions. I use NTS on server side for some pretty heavy calculations like map matching and it's performance is very good.

One of the best parts of NTS is it enables projections and loads of spatial abilities that you'd get out of the box, i.e. buffering a point or line or polygon, intersections, unions etc.

[charlenni]

For locations and boundingbox I would like to use our own custom types.

Than we have for bounding boxes Extent (BruTiles), Envelope (NTS) and BoundingBox (Mapsui) all for the same thing. That would be very strange. And geometries in NTS use Coordinates whereas Mapsui use Points, which again exist in NTS too.

[pauldendulk]

For locations and boundingbox I would like to use our own custom types.

Than we have for bounding boxes Extent (BruTiles), Envelope (NTS) and BoundingBox (Mapsui) all for the same thing. That would be very strange. And geometries in NTS use Coordinates whereas Mapsui use Points, which again exist in NTS too.

Some clarification of what I tried to say in this comment. What I have in mind is that the core of Mapsui is free of proper geometries, we will need a few types. I just had a look at the code and it seems it would suffice to have a Point, BoundingBox and Quad. Within a Layer or Provider you could choose to use a specific geometry implementation. A VectorLayer could use NTS. A TileLayer could use BruTile in the implementation. A VectorTileLayer could use something else. This would not limit the performance that could be achieved by a specific layer. But I need to investigate this further before I ramble on. Not sure how this will work out with MapInfo and the render callback.

You mention the BruTile Extent. In the current implementation this is only used when we directly work with BruTile classes. It is isolated in the TileLayer implementation and not in any other interfaces. It is not even used in the TileLayer interface. I do not see this as a problem. Typically Mapsui could have many different kind of data sources that makes use of a specific library for that data source. If NTS could be used in such a role I don't see that as a problem.

[pauldendulk]

No, I don't say, that NTS isn't supporting many types. I say, that Mapsui doesn't need many types. NTS is a very good library to do all you can imagine, but is this, what Mapsui needs? One of your goals is, to make Mapsui faster. I don't think, that we can reach this goal, if we use such a heavy library like NTS. So the question is, what could NTS provide for Mapsui, that Mapsui needs?

ah, thanks for the clarification.

When I see, how long 2.0 needed, than I would say, that we should make a roadmap for 2.1, 2.5 and 3.0.

You have a point. It should be a sprint towards the next release. I know we had this conversation before we started on 2.0 as well, and yet, somehow one and a half year has passed 😄

[charlenni]

Some clarification of what I tried to say in this comment. What I have in mind is that the core of Mapsui is free of proper geometries, we will need a few types. I just had a look at the code and it seems it would suffice to have a Point, BoundingBox and Quad. Within a Layer or Provider you could choose to use a specific geometry implementation. A VectorLayer could use NTS. A TileLayer could use BruTile in the implementation. A VectorTileLayer could use something else. This would not limit the performance that could be achieved by a specific layer. But I need to investigate this further before I ramble on. Not sure how this will work out with MapInfo and the render callback.

You should have two type of points: a screen version and a location version like Point and Coordinate or Point and GeoPoint. Than it is clear, which to use for what.

Perhaps the conversion to NTS would be a first step and leads to a version 2.1? Or is this a to big step?

[TheProme]

Those features are awesome. Just wanted to know how long would it take to make offline VectorTiles a possible feature?
I've seen charlenni's library but I doubt I can simply plug it into my project. Or maybe I could, but I surely need guidance for it :(