Open street maps local serve support

#130

Our local mesh group is running a server to distribute map tiles. Im reading thru the documentation and it looks like you have hard coded your personal tile server into the program. might it be possible to bring the option to set the server out into the gui? I dont know if the back-end of YAAC will pull tiles from the server the same way we do for our mapping program or not? Dose YAAC support the pointing as follows?in our php ini file we define a server with?inetTileServer['Topographic'] = "//{s}.tile.opentopomap.org/{z}/{x}/{y}.png"

I would like to not cash the tiles on the RPI.

For reference:?

Thanks for the Program 73 Mathison KJ6DZB

#131

It's not the same kind of tile server in YAAC as with the main OpenStreetMap tile server.

The "tiles" in YAAC are not raster images. They are geographically segmented pieces of the raw vector data, so that the YAAC real-time map renderer doesn't have to read through the entire planet's worth of data to render raster images of the streets in one small area. As such, YAAC doesn't have multiple "tiles" for different screen zoom levels; the raw vector data is rendered at whatever zoom level the user wants. This keeps the "tile" cache much smaller than for systems that cache different raster image tiles for each zoom level of the covered area. That's also why YAAC's street maps don't look like the tile-based web maps on OpenStreetMap or Google; my renderer isn't as good because it strives for speed rather than beauty for less powerful rendering machines, and it still has a few bugs in it.

I should mention that YAAC was deliberately designed to only operate off a local disk copy of the map data, specifically so it would still operate in installations without Internet service for downloading tiles. So the only way for it to operate without map files on a Pi is to not display maps.

You don't have to use my server to get updated "tiles" of segmented vector data. You can get a copy of the OpenStreetMap vector data (a database dump in .osm.bz2 or .osm.pbf format) and import it yourself. However, due to YAAC rearranging the data for more efficient rendering (so constant database lookups in different tables aren't needed), the importer is an enormous burden on the host computer; you need at least 150GB of free disk space to handle the import, and it takes hours (when I do the whole planet.osm.pbf file on my dedicated gaming server, it takes over 15 hours). A Raspberry Pi simply doesn't have the muscle to do it. But you can do it on a big enough machine to handle the burden, then zip or tar up the tile directory hierarchy on that system and restore it on each of your Pi computers.

The "tile" downloading feature in YAAC simply makes it easier for a given computer to only get the tiles it needs without having to waste disk space on other squares of the map, nor on manually figuring out which files to download.

The topographic layer of the map operates similarly, in that it stores the raw elevation data from the USGS in 1-degree-square files, and renders it at the desired zoom level on demand.

Hope this helps you understand my design philosophy.

Andrew, KA2DDO
author of YAAC

#132

I understand... A member has already rendered vector & raster data for our geografical area. I would like to point to that over the mesh network.?

Mathison

Show quoted text

On Wed, Jan 22, 2020, 11:51 AM Andrew P. <andrewemt@...> wrote:

It's not the same kind of tile server in YAAC as with the main OpenStreetMap tile server.

The "tiles" in YAAC are not raster images. They are geographically segmented pieces of the raw vector data, so that the YAAC real-time map renderer doesn't have to read through the entire planet's worth of data to render raster images of the streets in one small area. As such, YAAC doesn't have multiple "tiles" for different screen zoom levels; the raw vector data is rendered at whatever zoom level the user wants. This keeps the "tile" cache much smaller than for systems that cache different raster image tiles for each zoom level of the covered area. That's also why YAAC's street maps don't look like the tile-based web maps on OpenStreetMap or Google; my renderer isn't as good because it strives for speed rather than beauty for less powerful rendering machines, and it still has a few bugs in it.

I should mention that YAAC was deliberately designed to only operate off a local disk copy of the map data, specifically so it would still operate in installations without Internet service for downloading tiles. So the only way for it to operate without map files on a Pi is to not display maps.

You don't have to use my server to get updated "tiles" of segmented vector data. You can get a copy of the OpenStreetMap vector data (a database dump in .osm.bz2 or .osm.pbf format) and import it yourself. However, due to YAAC rearranging the data for more efficient rendering (so constant database lookups in different tables aren't needed), the importer is an enormous burden on the host computer; you need at least 150GB of free disk space to handle the import, and it takes hours (when I do the whole planet.osm.pbf file on my dedicated gaming server, it takes over 15 hours). A Raspberry Pi simply doesn't have the muscle to do it. But you can do it on a big enough machine to handle the burden, then zip or tar up the tile directory hierarchy on that system and restore it on each of your Pi computers.

The "tile" downloading feature in YAAC simply makes it easier for a given computer to only get the tiles it needs without having to waste disk space on other squares of the map, nor on manually figuring out which files to download.

The topographic layer of the map operates similarly, in that it stores the raw elevation data from the USGS in 1-degree-square files, and renders it at the desired zoom level on demand.

Hope this helps you understand my design philosophy.

Andrew, KA2DDO
author of YAAC

开云体育

Open street maps local serve support