more general importer / OSMImporter front-end

[GoogleCodeExporter]

Currently there is only the OSMImporter to import osm dataset. Adding a more 
general importer to handle other datasets would be a great enhancement.
I'd consider a OSMImporter front-end which converts other datasets into osm xml 
with mapnik concerned data which can be specified depending on the actual 
attributes of datasets.

Original issue reported on code.google.com by fever...@gmail.com on 17 Dec 2010 at 8:14

[GoogleCodeExporter]

I am not exactly sure what you mean. Importing a data set is most of the time 
very specific to the data set in question. I am not convinced you could 
implement an importer plugin that can handle arbitrary data sets.

Can you provide an example of a data source?

Original comment by veaac.fd...@gmail.com on 17 Dec 2010 at 9:42

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Typically, those OGR supported formats present a kind of dataset type. Such 
dataset is composed of  records, each records consists of geometry data and 
attributes(anything can be an attribute). For example, the esri shape stores 
geometry data in .shp and attributes in .dbf. The geometry part is aways fixed, 
while the attributes are totally unknown.
An OSMImporter front-end could simply map the attributes to corresponding osm 
tags based on user setting, and convert to osm xml which can be processed by 
OSMImporter. I have read some related threads in osm lists, they seem to write 
a shp to osm converter.
So, generally, user sets a mapping rule between his dataset's attributes and 
monav concerned osm tags, then convert to osm xml and finally processed by 
OSMImporter.

Original comment by fever...@gmail.com on 17 Dec 2010 at 12:07

[GoogleCodeExporter]

Ok, that might work. But, if those converters are available, this already 
should work with MoNav, shouldn't it?

Original comment by veaac.fd...@gmail.com on 17 Dec 2010 at 12:28

[GoogleCodeExporter]

Well, generally, current available xxx to osm converters are all script based. 
Most of them concentrate on handling geometry conversion and have lots of 
limits. The tags are simply copied from attributes. User have to edit the 
generated osm xml by himself.

this is the wiki page on osm : 
http://wiki.openstreetmap.org/wiki/Import/Shapefile

Original comment by fever...@gmail.com on 17 Dec 2010 at 2:24

[GoogleCodeExporter]

I wonder if every "feature request" is valid.
Wasn't the plugin interface designed so that *OTHER* people can code their own 
importer if they don't like the standard one? ;-)

Original comment by daniel.g...@gmail.com on 19 Dec 2010 at 12:42

[GoogleCodeExporter]

I have to agree with Daniel.

If there are tools that convert other data sets into OSM data you can use these 
to import this data into MoNav, but I will not work on any such tools. If your 
data set is important enough to be used on a regular basis I would advice you 
to write your own importer. You could copy most parts of the OSMImporter. I 
would also be happy to assist you should questions and problems arise.

Concerning development of further import plugin for MoNav by MoNav's 
developers: If there are public data sets that are applicable for routing and 
cover larger areas we will consider developing a plugin. If data sets do not 
fulfill these criteria yet, we would rather spend more time with other features 
for now.

I will leave the issue open for now, if you want to report on your undertaking 
as it might be useful for other users.

Original comment by veaac.fd...@gmail.com on 19 Dec 2010 at 3:58

[GoogleCodeExporter]

Original comment by veaac.fd...@gmail.com on 10 Jan 2011 at 8:48

• Changed state: WontFix