Replies: 0 comments 15 replies
-
|
I would consider a way to extend the library with plugins or something similar for that. |
Beta Was this translation helpful? Give feedback.
-
|
Plugins aren't really a thing on mobile, even if we may call some things plugins. Yeah, you can probably find some counter-examples, but they're going to be a bit weird or specific. Best to say it's not really a pattern we use on mobile much. But what can be done is auxiliary libraries. Rather than adding this functionality, we add hooks and implement it in another library. To the developer it just shows up as "oh yeah, I have to link in this other library too". Doesn't change too much. If any of these are funded, we should have the conversation about where they go at the beginning of the effort. |
Beta Was this translation helpful? Give feedback.
-
|
auxiliary libraries seems like another name for plugins IMHO 😀 the main aspect is if you get it when you add the core library, or do you need to install a separate package. |
Beta Was this translation helpful? Give feedback.
-
|
Usually dynamic loading is the difference, I think. But I agree, we don't want to bloat the core library anymore. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I think adding a "hook" architecture enables plugins / additional libraries without limiting what the developer can imagine to do. (Which is a real strength of MapLibre on the web with |
Beta Was this translation helpful? Give feedback.
-
|
Supporting EPSG:3395 and ESPG:4326 Map Tiles (Vector Tiles, Raster Tiles, Terrain-Elevation Tiles) is crucial for US Government Adoption where the Defense Geospatial Working Group/National System for Geospatial Intelligence mandate they can't use EPSG:3857 Supporting GeoPackage SQLite format
Gpkgext_vt_layers Supporting different Tile Matrix Sets too. https://gitlab.com/imagemattersllc/ogc-vtp2/-/blob/master/extensions/14-tile-matrix-set.adoc It would be great to add Spatialite support
It also supports OGC WFS Web Feature Service https://www.gaia-gis.it/fossil/libspatialite/wiki?name=WFS , ST_ Contains, ST_Within
|
Beta Was this translation helpful? Give feedback.
-
|
Great list! Right, GeoPackage. That's a good one. A very complex one, but an excellent suggestion. For Tile Matrix Sets what he means here is loading things other than in a quad tree form. The OGC standards like these sort of floppy trees which can have random tile sizes at a given level. It's as annoying as it sounds and it's really, really hard to guess how much data is in each because they don't enforce anything. But it's a thing they do. I thought there was a license issue with Spatialite. Have to look into that if it comes up. Personally I'd draw the line at actual vector operations. But that's just me. Great stuff! |
Beta Was this translation helpful? Give feedback.
-
|
No license issue with spatialite it's got very good open source licenses that permissive There is SPL.JS web assembly version too https://github.com/jvail/spl.js/ https://github.com/jvail/spl.js/blob/main/doc/spatialite_functions.md Spatialite also handles offline routing with its virtualRouting https://www.gaia-gis.it/fossil/libspatialite/wiki?name=VirtualRouting and OSM data you can use to build offline network enabled database |
Beta Was this translation helpful? Give feedback.
-
|
I was searching the internet for a very long time to find a good example of doing offline routing on mobile devices and haven't seen a single post about the above mentioned technologies... 😕 |
Beta Was this translation helpful? Give feedback.
-
|
Huh, that's really interesting. This corner of geospatial will benefit from mixing a bit more with that corner of geospatial. |
Beta Was this translation helpful? Give feedback.
-
|
I can't argue with that 😀 |
Beta Was this translation helpful? Give feedback.
-
|
For working with features as dynamic raster tiles, linking tiles to featured and working with raster tiles in any SRS the NGA GeoPackage Native library Android and iOS is great |
Beta Was this translation helpful? Give feedback.
-
|
These apps currently using mapbox |
Beta Was this translation helpful? Give feedback.
-
|
I wrote a version for WhirlyGlobe using that GeoPackage interface library years ago. It had some performance issues and a very Java-like view of the world. Beats writing your own though. |
Beta Was this translation helpful? Give feedback.
-
|
This has been a great discussion. It's reminded me of a few things, told me some things I never knew, and suggested a path forward for adoption by the parts of the US Gov. I'm dusting off my contacts in that world and plan to have some useful conversations in the next few months about funding. Thanks! |
Beta Was this translation helpful? Give feedback.
-
General Purpose Data Loading Architecture
Here's some functionality we'd like to add to MapLibre. This is one proposal of several for Native and if you'd like a little context and our strategy there's an overview. Short version: Native first because we know it, then circle back and propose web.
It's hard to get new data into MapLibre. There are some clever hooks on the web side, but very little on Native other than "turn it into GeoJSON or vector tiles". We can do better.
Motivation
Getting new data sets into MapLibre is just difficult. We could get into the history of why, but everyone was acting reasonably and this is simply the outcome. Now that MapLibre is an open source project it should be more welcoming to new developers, new users, and new data formats.
I don't see MapLibre used much by the US government and I have a theory as to why. Those users tend to have a laundry list of data formats, often specific to them, which they want to import. And sure, most of those formats are not well suited to dynamic loading. But... they could work well enough for small areas or as a proof of concept or... well it's surprising what can be 'good enough'.
This problem is more acute on Native platforms. On the Web we tend to stand up a fair bit of infrastructure to support a site. Converting data to what the map toolkit wants is just another part of that. But on Native, our (Wet Dog Weather) experience has been different.
Particularly in aviation, but in other areas as well, developers have their own data they're bringing along. There's more of an emphasis on getting the toolkit to read your data, rather than standing up a pipeline to convert your data to the formats supported.
Having a quick on-ramp for a variety of data formats will get more developers into the system. Then they can think about data pipelines and performance. Or not. But at least their data would show up.
Format Developer Perspective
Let's start with what the developer ought to see when they decide to import their beloved format into MapLibre Native. Other than documentation, of course.
For pyramid tile based formats, the interface would be something like this:
We'd need to expose an internal geometry format for returning data as it's been parsed. That would need to point into existing style specifications and a whole host of complexity.
At its simplest, a format developer should be able to get their tiled data into the system this way.
One Time Loading Requests
Tiled data is obviously best for MapLibre Native, but there's no reason we couldn't help load non-tiled data sets. Right now you just convert them into GeoJSON, but we could make that a bit more flexible.
Larger single data sets have a memory problem. You need to load them, convert them to a more friendly format, hand that over to MapLibre and let it convert them to its own internal rendered form.
What could help with that is a bit of streaming functionality where a loader can hand over geometry as it goes, rather than all at once.
Structured Data That Isn't Tiles
Pyramid tiled data sets aren't always for the best. With vectors we end up duplicating a ridiculous amount of data between levels and spending time loading too big a tile or too many small tiles.
A decade ago we had a lot more nascent geo-diversity in these sorts of formats. Then the monoculture of vector tiles took over. A few new efforts, like PMTiles, are pushing their way through the blasted geo-soil and they deserve encouragement.
PMTiles is tile based, but not all these efforts are. Some used K-d trees and even good old WMTS, a geo standard, takes a more flexible approach to its coordinate systems.
This new loading architecture would get us closer to allowing those sorts of formats to load, but we'd still need a few more steps.
First, we need a way for the developer to decide what to load. Either to replace the spatial loading logic or just do it externally. One of our other proposals has some ideas in this area.
Internal Loading Architecture
It's worth examining how this would work internally. We had a fairly advanced data loading architecture in WhirlyGlobe. It allowed us to consume client-specific data formats without having to make toolkit-wide changes.
Without getting deeply into the weeds, we broke it up like so:
Breaking data fetching away from parsing was key, as was building renderable data in parallel off the main thread.
Discussion
For WhirlyGlobe only ever built a Quadtree based loader, though it was still pretty flexible. It could load multiple levels of detail at once, combining them on the fly. For MapLibre we'd try to make the loader flexible enough to let someone implement a non-quadtree structure.
This is fairly low level stuff. Most developers aren't going to use it, but those that do will open up new possibilities for the toolkit.
Beta Was this translation helpful? Give feedback.
All reactions