GNOSIS Map Tiles
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 295 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/43461 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
00:00
Vector spaceOpen setEndliche ModelltheoriePoint cloudFormal languageComputer programmingSubsetSource codeSoftware development kitService (economics)Server (computing)Mathematical optimizationKeyboard shortcutSoftwareObject (grammar)Orientation (vector space)Reflection (mathematics)Modul <Datentyp>AerodynamicsAndroid (robot)Computing platformFreewareGraphical user interfaceType theoryNumbering schemeCompact spaceArtistic renderingClient (computing)Computer hardwarePoint (geometry)Equals signAreaMatrix (mathematics)Standard deviationVisualization (computer graphics)Programming languageTessellationNumbering schemeRepresentation (politics)Server (computing)CodeDifferent (Kate Ryan album)QuicksortTestbedAugmented realityClient (computing)Classical physicsLatent heatGraphical user interfaceFocus (optics)Computer programmingWeb 2.0SoftwareFile formatData storage deviceSubsetEndliche ModelltheorieObject (grammar)Military baseMereologySoftware development kitSlide ruleRepository (publishing)Game theoryLevel (video gaming)Physical systemBitAreaCross-platformCartesian coordinate systemOpen sourceModel theoryPoint (geometry)Content (media)Link (knot theory)Position operatorLibrary (computing)Point cloudVector spaceLocal ringDynamical systemTask (computing)Formal languageType theoryComputer hardwareGreatest elementOrientation (vector space)Artistic renderingSphereMathematicsService (economics)DampingLine (geometry)Degree (graph theory)Network topologyKey (cryptography)Set (mathematics)Self-organizationPolygonRing (mathematics)Multiplication signSpeciesOpen setWeightDialectVideo gameSource codeReflection (mathematics)Category of beingInstance (computer science)PlanningImage resolutionConnectivity (graph theory)Transport Layer SecurityComputer animation
07:08
Matrix (mathematics)Standard deviationEquals signAreaConvex hullGraphics processing unitArtistic renderingTessellationPolygonVertex (graph theory)Data storage deviceLocal ringDirected setDatabaseAttribute grammarVector spaceNetwork operating systemRange (statistics)Level (video gaming)Compact spaceActive contour modelRepresentation (politics)Point cloudSoftware testingEndliche ModelltheorieVisualization (computer graphics)Slide ruleRevision controlTessellationLine (geometry)QuicksortGraphics processing unitMatrix (mathematics)Data storage deviceRight anglePrice indexStandard deviationNumberSoftware testingZoom lensData analysisEndliche ModelltheorieRule of inferenceTouch typingImage resolutionCompact spaceMereologyComputer configurationPolygon meshMultiplication signHeat transferPoint (geometry)File formatComputer clusterPoint cloudCodeAreaBitProcess (computing)Level (video gaming)Maxima and minimaOrder (biology)Degree (graph theory)Computer filePole (complex analysis)PolygonDirection (geometry)Boundary value problemVector spaceDistribution (mathematics)Range (statistics)Electric generatorAttribute grammarInformationVertex (graph theory)CausalityFlagModel theoryNetwork topologyActive contour modelTask (computing)Software developerSubject indexingView (database)TriangleExtension (kinesiology)Query languageLocal ringMetropolitan area networkThomas BayesState of matterReverse engineeringShared memorySequelDatabaseSet (mathematics)WeightComputerPhysical systemLink (knot theory)MultiplicationDistortion (mathematics)Proxy serverPrototypeComputer animation
13:39
TestbedOpen setModel theoryOvalTask (computing)Computer programmingSource codeCodeMappingLevel (video gaming)Frame problem2 (number)Focus (optics)Physical systemFormal languageEndliche ModelltheorieDigitizingRight angleCodierung <Programmierung>TessellationTestbedSet (mathematics)View (database)Computer animation
14:45
Formal languageVideoconferencingMultiplication signVector spaceVisualization (computer graphics)TessellationLevel (video gaming)Computer animation
16:07
TessellationSet (mathematics)Level (video gaming)Physical systemRevision control
16:53
Revision controlModel theoryData storage deviceLevel (video gaming)SpacetimeTessellationVideoconferencing
17:23
Right angleComputer animation
17:42
Bit
18:01
Revision controlWeb 2.0Client (computing)PlanningLevel (video gaming)Image resolutionTessellationModel theoryArtistic renderingVisualization (computer graphics)Polygon meshLine (geometry)Digital photographyInteractive televisionCurve
18:58
PolygonLine (geometry)TessellationCurveVector spaceModel theoryFile formatLink (knot theory)Source codeFreezingAndroid (robot)Revision controlWebsiteGroup action
19:47
Annulus (mathematics)Source codeLink (knot theory)Interface (computing)Touch typingComputer animation
20:11
CoprocessorVideoconferencingBitAndroid (robot)ComputerData storage deviceFile format
20:31
InformationModel theoryCovering spaceDatabaseDigital signalPoint cloudPhysical systemNetwork topologyTexture mappingHypermediaReal numberVideoconferencingData storage deviceComputerFile formatWeb 2.0Service (economics)Form (programming)Extension (kinesiology)Translation (relic)TessellationCuboidServer (computing)Level (video gaming)Different (Kate Ryan album)Vector spaceGeometryClient (computing)Self-organizationSource codeComputer animation
21:10
Inclusion mapInfinityMechanism designData exchangeSystem callCuboidVirtual machineData conversionPressurePoint (geometry)Dynamical systemModel theoryTessellationReal-time operating systemDevice driverCombinational logicFile formatObject (grammar)Shape (magazine)Electronic visual displayComputer fileData modelFile archiverComputer animationLecture/Conference
Transcript: English(auto-generated)
00:08
So let's resume our session with us. We have now Jerome Saint-Louis from Quebec in Canada. Hi, everyone. I'm Jerome Saint-Louis from HRA in Canada.
00:21
Today I would like to talk to you about our multipurpose format for tallying geospatial data, for storing geospatial data and different types of geospatial data. Just to give you a little bit of an overview of what Gnosis is, so in 2014, we started
00:44
building this entire geospatial software stack. Basically, the main components, we have a visualization toolkit, a cross-platform library for visualization using hardware-accelerated
01:00
rendering, OpenGL. And we also have a map server. And we also have a GIS tool, and things you can do in the GIS tool include things like producing the tiles, styling your data, importing different types of data sources.
01:21
And so that's the basic thing. And all of this is built on top of a more general-purpose software-developing kit that we've been developing since 1997. Even some of it goes back to 1996, which is our HRA SDK, which is all open source. It's actually part of the official repository
01:42
on Debian and Ubuntu. It's a HRA SDK package. It started out as a game library, basically, to be cross-platform. Supports OpenGL, supports Direct3D. And we also built a full cross-platform toolkit,
02:01
a GUI toolkit, so you can build applications. And it's cross-platform. You can run them on Linux. You can run them on Windows, on Android, on the Mac. Now you can do WebAssembly. We have it on Odroid, on Tizen, which runs on my Samsung watch, and FreeBSD. So it's very, very cross-platform from the bottom up.
02:21
And so it sits on top of this whole SDK. So that's the basic idea. And we also have our own programming language, which is called EC, which is compiled and native. And all of our software is built in EC. So what EC is, it's a superset of the C language, so it's compiled and native.
02:42
And then we add things like object orientation, properties, reflection, dynamic modules, sort of the features you find in modern programming language. So you get the best of both worlds. You can efficiently, rapidly code very fast in high performance code. And that's why we use it to build a gnosis.
03:02
So eclang.org is the home of our language. The language was designed in 2004. So this is just sort of the background for my talk here. And then what we have is the gnosis map tiles, which is the focus of this talk, which is basically an open format
03:20
to store geospatial data. And the types of geospatial data you can store in there includes, of course, vector features, so points, polygons, lines, and then imagery. And then you can also store gridded coverages like elevation models. You can also store point clouds.
03:40
So we're working on importing all the contents of LAS files into this format. And we can also either embed or reference 3D models with sort of a position and orientation of the 3D models and referencing a shared 3D model. And we also have a format for encoding 3D models
04:03
in a very efficient way, which is called e3d. As a link here to the draft specifications for e3d. But you could also use other formats like glTF, for example, to encode the models either inside the tiles themselves or reference to share them as you have tiles with points
04:22
and then each point point to the same models that you want to have different places if they're instantiated, if you have geotypical models. And the big advantage of diagnosis map tiles is it all works with the quadtree system. So you have, as you go, you zoom out,
04:42
you get your lower resolution data. So it's all quadtree based. And so we do generalization of the vector feature. So it's similar to the Mapbox vector tiles concept as well for vector data or the geotiff tile pyramids, it's the same idea. And it was just a nice thing is you have one format
05:00
that can store all of these different types of geospatial data. We actually designed a global grid, which works well with the WGS 84, referential reference system. And the advantage of diagnosis global grid is that you're not, when you go to the polar regions,
05:23
you don't waste data because we try to approximate equal area. So that's, the next slide is about that. So I'll talk a bit more about that in the next slide. We does also, so this is the sort of the tiling scheme we've been using with gnosis map tile so far,
05:41
but we could also, there's no reason why we could not use this with other tiling schemes like the classic Web Mercator or any other tiling scheme. The focus of the format is to be compact. So it's all binary representation of the vector data. And it uses techniques like localization of the coordinates
06:04
so you can use as little bit as possible, but still have good precision. And it's also designed with the performance of client side, hardware accelerated rendering in mind. So that's sort of the main purpose of this is all our software, what we do is a lot of 3D visualization.
06:21
So we want a high frame rate and all this. A lot of the background, so that's a link up there to the GMT format specifications that you can take a look, but it's slightly outdated right now because during the OGC test bed 14 last year, we were working on this city GML
06:42
and augmented reality task. And as part of this, we did a lot of enhancement and those are not yet, I've not made it yet into that. I was hoping to do that before this talk, but I didn't have the chance. So this talk is actually more up to date right now at the bottom.
07:03
And so this is the global grid that I was talking about. And I don't know if you can see well here, but basically the whole world is divided at the level zero into eight tiles. So the North Hemisphere is four tiles, the South Hemisphere is four tiles. They're all 90 degree by 90 degree tile.
07:21
If you're familiar with the blue marble next generation distribution from NASA, it's the same tiles that you have there. And then when you go to the next zoom level, the rule is very simple. It's almost a quad tree, but every time you go to the next level,
07:40
well, you cut in four, but if your tile touches the pole, you don't cut the part that touches the pole. So you end up with only three tiles instead of four for the part that touches the pole. So that's the simple rule. You can see here, that's the next level down. So you'll have wider tiles at the pole
08:01
and a bit smaller and a bit smaller. So the idea is that the tiles actually don't look distorted when you look at them, even though you're using WGS 84 cause it's approximating the equal area. So it's like, of course it's not exactly equal area, but the compromise is that it makes it easy because it's easy to cut because it's aligned
08:22
with the latitude and longitude lines. And the main purpose of this is that it's great for 3D because in your 3D view, you can mix different levels. So the task closer to you will be higher resolution and the tiles further behind will be bigger tiles, lower resolution data. And the great thing is the upcoming OGC tile matrix
08:43
set standard will support a variable with tile matrices like these. So that's, we can officially describe this in the new tile matrix set standard that's coming. So that's about it. The details about this format and some code
09:01
to compute the tiles and all this is here on this link. And now to talk a little bit about how the data, the vector data is actually stored inside the tiles. So if you have polygon data, which is the more complex case, that the polygons are actually pre-tessellated
09:23
using a delaunay tessellation. That's something I forgot to include in this slide as well is we'll also include the center line after the delaunay tessellation, but before the tiling so that you can have your nice curved labels on your lakes and your rivers and all that.
09:41
And it's ready for the GPU to render because it's already tessellated and GPUs work with triangles. So you have your vertices and your indices all ready to throw at the GPU. We also share vertices of course with indices. The indices index the different vertices. So at the same point it will only be encoded once.
10:02
So it's safe storage, but it also ensure that it's topologically correct when we're describing the polygon with a triangle mesh like that. Each vertex is quantized to the local tile extent using 16 bit for both the latitude and the longitude for each vertex.
10:21
So we maximize the precision by using the minimum amount of storage. And all of this we store in a direct file base data store as opposed to inside a database. So we have the very fast access, but in order to not have like a very, very large number of files, we recruit them in top pyramids
10:40
with some range of zoom levels. As this way we have a reasonable number of files versus a reasonable file size for each top pyramid. And the attributes for the vector data are stored separately in a SQLite database so that you can do your fast queries and get information about the data.
11:03
Oh, the one thing I forgot to mention about the polygon is we also, so the tiles are actually clipped exactly at the boundaries rather than using an overlap. And the way we resolve, for example, when we have a polygon and the tiles cut straight through, we'll mark the vertices or the segments
11:22
that were artificially introduced by flags at the vertices saying that these are where the tiles reconnect together. So it's easier to reconstruct the topology of the whole data together and work with it for data analysis purposes, not only visualization.
11:44
So the future roadmap for this is we're still working on maybe a version which is contour based instead of a triangular mesh. That would be another encoding option. And this may have some advantages. It may make it a bit smaller. So we're studying this right now.
12:03
We're also trying to improve compactness. I think we can get it even more compact. And so it's gonna help transfer speed and processing speed and all that. We're also doing additional testing with the visualization and storage of point cloud. So the idea with point cloud is that you do,
12:21
we have multi-resolution point cloud. So you could have the whole world as a huge point cloud. And as you zoom in, you're quite true. You get your more dense data, right? So you can do clustering or you can do filtering of the point cloud as you go to the lower version. So we're still working on actually testing this
12:41
in practice. Also, so we have the 3D visualization or the 3D models. We have some prototypes of that, but we're going to do additional testing. There's a model where we can do spilling. So instead of cutting the models, you can have sort of spilling onto the next style.
13:00
And right now, so we're working on it. There's some provisions for that in the standard, but we have to do additional tests of that to make sure that you're not missing models because there's a model from the tile behind that you could actually see in the tiles that you have selected for your view. And it would be great if we could have support for this
13:22
in other tools like GDAL and OGR and all of the other tools that use GDAL and OGR could use this. So we're interested in contributing support for this or helping with the development of this if there is interest.
13:40
These are some screenshots using our tile. So this is a Google Maps imagery draped on a digital elevation model from viewfinder panoramas, which is styled as GMT. And this is another, again, Google Maps with viewfinder panorama. And the thing is, we can do nice frame per second.
14:01
It's just go anywhere in the world and right away, the tiles come up. It's very fast. This is the 3D. This is actually sourced from CDB from Flight Safety. So that was in the OGC Testbed 13 and Testbed 14 Innovation Program activities.
14:21
So this is actually, all the layers are converted to GMT. So the imagery, the terrain, the 3D models, it's all converted to GMT and e3D model encoding. And this is another same data set but another view with Central Park, same idea.
14:45
And this is OpenStreetMap. It's hard to see right now. So this is OpenStreetMap converted to GMT layers using this vector data with styles applied. We're still working on improving the styling of this and tomorrow, my talk will focus
15:02
about our styling language for styling vector data mostly. And yeah, thank you very much. And I don't know how much time we have. If we have some extra time,
15:20
maybe there's some videos I could show or we could do questions. We have five minutes. Five minutes and then questions. So I could show one video for me. Don't forget your microphone.
16:01
Oh yeah. So this is an example here. So this is actually using 3D tiles here but then we're converting the 3D tiles into our Gnosis map tiles to import into our system.
16:25
Both CDB and 3D tiles, we have a system to import it and then convert it into our Gnosis map tiles which our engine uses internally. So that's the data set that I was showing earlier
16:40
from flight safety. And this is, so you can see this is the whole earth. You can have different layers. So all of this you can show. So this is the CDB version. The elevation model again is stored in CDB
17:01
and then we can import it into our Gnosis map tile. So it's very easy, very portable. You get the, you save storage space too. So that's, this is much of the same thing. So yeah. Thank you. Any questions? Okay, you can show another video if you want
17:20
or we can go into the questions. Let's show another video. Further than the CDB floor. Ah, okay. Interesting. This is what it is.
17:47
So this is just an overview of a bit our whole, what we can do. So the whole earth, different layers.
18:03
The idea is to have high performance, right? And so we're still working on deploying the web version but technically using WebGL and WebAssembly we can go get the same amount of performance with the clients. That's the great thing about client-side rendering and the great thing about the Gnosis map tile
18:20
is you minimize the data you have to send and it's easy to cache on the client-side. So this is a very high resolution model. This is actually from photogrammetry and this is actually a KML model that's placed on top.
18:42
Can I still interact with the mesh so it's not only visualization. It's going to show some of the, this is the natural earth
19:01
and then we're gonna do some styling so we have a labeling engine too that works with that. Like I was saying earlier, it's nice to have in your polygon tiles that you have the center lines before it was styled so you can apply some curve labels but that's still something we're actually implementing but the format supports that.
19:23
This is styling, this is actually vector data draped on top of the model. This is the line coverage from New Zealand with vector styling applied to the polygons. This is from the LINZ, one of the New Zealand agencies.
19:46
I have it up on our website, the link is there with the source. This is showing the Android version, touch interface layers.
20:04
So while the film is rolling, we can pass on to the questions. Who wants to ask something from Jerome? You're all marveled with the video. This is a small Android device. It's a very tiny thing.
20:21
It's a bit like a Raspberry Pi but it has a GPU in it so you can get nice performance. Sorry, go ahead. Am I correct in understanding that it's meant as a storage format on computers and not so much as a delivery format for the web? So we're using it for both actually.
20:40
So now in our OGC API service, when you request a tile, you can ask for it in the GMT format so it can come in this way but we also have a data store to store it locally and actually the data store for our organosis server is the GMT format but you can on the fly request different extent and you can convert it to map box vector tiles
21:02
or geo JSON or GML and it's gonna do the translation on the fly from that. So you have the choice but for our client, that's our preferred data exchange mechanism so it is meant for the data delivery. Who else would like to intervene?
21:30
Is it all about pre-processing so you have prepared all the tiles in advance or are there any thoughts about having some real-time data in tiles?
21:45
I'm not sure I understand. So our preferred approach is to, like for example, if we import some shape files or some other formats that we support, we'll do the conversion and prepare our GMT archives but if you want, you can also see it live from a shape file
22:01
or from some other format driver and you visualize it live and internally we'll use something close to that data model. Does that answer your question? I think maybe. So if you wanna display moving objects that you're streaming data about vehicles or whatever
22:22
and you can put it, are you able to put it into the tiles or are you just rendering it next to the tiles? Well, I guess it depends what would be the advantage to tile it. It depends how much data you have, right?
22:40
Like, I'm not sure. As far as I understand, the question is if you have static data that are rendered and shown and combine it with real-time data. So of course, we can do that. We can combine dynamic layers on top of the tiles. I'm wondering if you mean, do you wanna tile that dynamic data and then show it? Yeah, I'm not suggesting you have to do either
23:02
but our engine can do it but I mean, and you could convert it to tile and then show it and then re-tile it again but if the data keeps changing, there's not really a point to put it in a tile in that intermediate step, right? One last quick question.
23:23
Okay, so we'll leave it there. The session resumes at half past five. Thank you very much, Gerald. Thank you very much.