Frédéric Rodrigo

Makina Maps is a new stack to produce vectors tiles on request from updated OSM database. The same thing we except from Mapnik, osm2pgsq and mod_tile stack, but for vector tiles.

The Vector Tile is a mapping solution where the Data Vector Tiles are served separately from the style and only assembled eg. in the web browser. Makina Maps is new Vector Tile Server build using Docker and based on Imposm, OpenMapTiles, TileServer GL and NGINX. The stack can be easily and quickly set up. The components allow to import OSM data into a Postgres database and server tiles on request. The tile caching is included. Using Imposm the OSM data can be update and the tiles cache invalided. This stack can be used as tile server for on request query and support fast update after many improvement was done and still in progress to OpenMapTiles. Fist, it requires to speed up the OpenMapTiles data layers query to server pretty quickly new tiles while users browsing the map. Secondly, it need to be able to update the database as fast the OSM diff update are coming and without locking the database. In complement of building and serving vector tiles, Makina Maps can hosts vector tile styles and is able to build and server raster version of these tiles. There is also the possibilities to server stored tiles from MBTiles like raster or eg. RGB dynamics light hill shading.

Replacing the classics "Continue for about 200 m then turn left" by guidance instructions in more natural language automated from landmarks are still a research topic but aims to allow users to move with more confidence. The objective is to test it on an indoor/outdoor pedestrian route calculator. Anything that can be used as a landmark is extracted from OpenStreetMap, then categorized and classified to annotate the route: relevance, visibility, relative position…

Replacing the classics "Continue for about 200 m then turn left" by instructions in more natural language with landmarks incorporation. It aims to allow users to move with more confidence in and around railways stations. Guidance instructions in more natural language automated from landmarks are still a research topic. Innovation & Research branch of SNCF, French National Railway Company, has delegate to Makina Corpus the task to implementation the state of the art in this field. The objective is to test it and then improve an indoor and outdoor pedestrian route calculator under development. Anything that can be used as a landmark is extracted from OpenStreetMap, then categorized and classified. The landmarks are evaluated to annotate the route: relevance, visibility, relative position.… The process have to deals with indoor and outdoor but also as points or large landmarks. We talk on subjects like evaluate how OpenStreetMap objects are suitable to be landmarks. We also expose how check for objects visibility based only on OpenStreetMap data, or how to allow landmark to be visible from outside a building or room depending on the outdoor or indoor status of the observer. The railway stations context has the particularity to require support of transition between indoor and outdoor.

Osmose-QA is a Quality Assurance tool pointing issues on map, but also able to compare external data set to OpenStreetMap. First part is about the new support of MapCSS rules in Osmose-QA and the opportunity to share rules with JOSM and other tools. Second part is on integration of external data from Mapillary photography objects extracted by AI and from OpenData. It is also on the challenge to deals with lots of OpenData.

At the beginning, Osmose-QA is a Quality Assurance tool pointing issues on map, but also able to compare external data set to OpenStreetMap. First talk part is about the new support of MapCSS rules in Osmose-QA. MapCSS language was primarily designed as way to style map objects, it look like the web styling language CSS. The base of MapCSS is to use selectors to filter objects. JOSM already use it for map styling and validator. This new implementation of MapCSS in Osmose-QA allows to write rules more easily. It also allow to reuse JOSM validator rules set. Next step would be to run Osmose rules in JOSM. It’s a great opportunity to share rules across tools and projects. But come the question on how to share and manage this rules while considering tools particularities. Second talk part is on external data comparison (aka conflation) with OpenStreetMap. It permits to point issues and evaluate the coverage, lastly it allows fixing and integration into OpenStreetMap. The more we wait, the more there is OpenData sets available. How Osmose-QA can try to addresses this issue of already too many OpenData set available. Beside OpenData from authorities we also have street objects extracted by Mapillary AI from street photography. Finally, what about the limit of the current model and how we may go further.