Does mapsforge work with non-OSM data?

[Leith Bade]

Hi,

I am working on a topographic map app and mapsforge is the only vector map renderer for Android I can find.

However it appears mapsforge is designed for OSM data but I will not be using OSM data.

How easy is it to use non-OSM data sources with mapsforge?

How much OSM specific stuff is hardcoded?

Leith

[Ludwig]

There is actually no dependency at all in the renderer, i.e. on a device, at all, if you exclude the rendertheme.xml which supports the conventions used by OSM. But this can easily be adapted/changed to take other data into account and there is nothing hardcoded that would say OSM.

The only 'dependency' is in the mapfile writer as it takes OSM-formatted data as input. However, it is generally not difficult to format other data into the OSM format, so that the only adaptation required is to define your own tag-mapping.xml (the file that describes how data is included into the mapfile).

For topographic data the two problems you will be facing are to simplify your topo vector data sufficiently that it is small (=fast) enough to display on an Android device while avoiding complicated nested geometries (which are known to introduce problems).

HTH

Ludwig

Leith

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Leith Bade]

Thanks for your fast reply.

I tried looking for info on how to convert stuff into OSM format but pretty much everything on the Internet is about using the existing OSM data...

From what I have found it appears that the map writer uses Osmosis. Osmosis uses a PostGIS database to store the data.

So I guess the problem then is to convert my data (which is in a ArcGIS geodatabase) into an OSM database.

Do you know how you go about creating a blank database for Osmosis without importing OSM data?

I could then write SQL scripts to import ArcGIS database into the Osmosis database.

Thanks,
Leith Bade
le...@leithalweapon.geek.nz

--
You received this message because you are subscribed to a topic in the Google Groups "mapsforge-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mapsforge-dev/32ygIxMLpO0/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to mapsforge-de...@googlegroups.com.

[Ludwig]

No, osmosis is just an OSM conversion program, it does not actually used PostGIS (but it can convert OSM data into formats suitable for postgis). So you do not have any dependeny on a postgis installation.

The input for the mapfile writer is either the OSM XML format or the protobuffer format. The protobuffer format is really just for machines, but the XML format is very easy (but extremely verbose). You really want to use the OSM XML format.

Best to restrict yourself to nodes and ways in the OSM format. A node is a geo point (with id and with possible attributes), a way is a line made up of nodes (with id and with possible attributes). Avoid relations, supporting them is extremely difficult. So, writing OSM files is actually not difficult: if you have a line, take every point on the line an write out a node element, then write out a way element that references all the nodes. Since you are not importing into OSM, you can just make up the required ids on the fly.

Easiest way to see what an OSM data file looks like is to download a piece from OSM and open in an editor. A proper description is here http://wiki.openstreetmap.org/wiki/OSM_XML

Not sure if that makes any sense.

Ludwig

[Leith Bade]

OK, I understand it now.

Should be very easy to write some Python to generate the OSM XML.

Thanks,
Leith Bade
le...@leithalweapon.geek.nz

[Leith Bade]

Hi,

OK, I managed to write a Python to XML convertor for my data and it imports OK into the app.

However I have to say OSM XML is painfully verbose and generates ridiculously large files that are slow to process.

Also supporting polygons with holes via relations is a pain too.

However I have a few questions about the Douglas Peucker simplification. The documentation mentions that simplification-factor is applied at the base zoom level. But does the converter also apply 2x the simplification at higher zoom levels so that the geometry on each zoom level is simplified for the screen?

Also I noticed the demo app is rather sluggish when it is rendering tiles and scrolling - and this is on my quad-core HTC One. Google Map runs very smooth with similar geometry detail and can rotate etc while it is at it. Does the program use multithreading?

Thanks,
Leith Bade
le...@leithalweapon.geek.nz

[Leith Bade]

Just discovered the program fails to render polygons properly. It doesn't fill the polygon properly almost like there is a leak of some sort.

JOSM can display the XML file properly though.

See the attached file.

Thanks,
Leith Bade
le...@leithalweapon.geek.nz

[Ludwig]

Well done to get so far so quickly.

I totally agree with you on the OSM XML file format, but you will have to live with it.

Simplification: inside the map file the data is stored in tiles for several zoomlevels at the same time and the lowest of the zoomlevels is the base zoom level for that tile. So the simplification is applied for that zoomlevel.

Threading: there is only a single thread that renders tiles, making it slower than it needs to be. But making it effectively multi-thread will require a bigger rewrite than is obvious. I tried once with a simple approach, but while this ran than in multifple threads, it did not make the app run on multiple cores, the app was simply time-sharing between the threads, resulting in no gain whatsoever. Fixing this is something that might come after 0.4. Last time I checked, Google had a few more people work on their map product than mapsforge, plus they might know Android a bit better.

The one thing you can fix are the polygons, but this is tricky. What possibly happens in your case is that rounding and simplification of polygons introduces invalid geometries, e.g. where an inner polygon gets simplified so that it cuts through its outer polygon with the result that the whole polygon becomes invalid. Also complex multipolygons (e.g. a crater of a volcano, i.e. a ring if you are looking at it from a elevation point) might not work well. There has been a fix for some of this in the latest rewrite branch, particularly a workaround in some of the invalid polygons.

HTH

Ludwig