Talk:Converting map data between formats

Discuss Converting between formats page here

---

No raster file format

this page is more on vector format no raster file format -- User:France-59-valenciennes 07:03, 2 May 2009

That's because you don't tend to be able to do interesting conversions once a map has been rasterized. In terms of conversions, the most interesting thing you can do with a rasterized map is apply OCR techniques or manual techniques to turn it back into vectors! What kind of raster conversions did you have in mind? -- Harry Wood 09:25, 2 May 2009 (UTC)

Data formats or programs?

I am a bit baffled by some of the recent additions to this already huge list, such as these:

File type	Extension	To Import into OSM/GPX	To export from OSM/GPX	Discusion/Comments
GroundTruth	gpx, xml	GPSBabel, Prune	GPSBabel, Prune	.osm to .img
JOSM	?	?	?	*.osm to swt
Kosmos	?	?	?	osm to GDI+ and java swt
Mkgmap	?			.osm to *.img
Manifold	map	no	no	import osm data and raster both from server
NoniMapView	?	?	?
Osm2gml.py	?			.osm to gml
Osm2shp	?			.osm to shapefile
Osm2pgsql	?			.osm to pgsql
Osmarender	?			.osm to SVG
Osm2KML	?			.osm to KML
Osmosis	?			.osm to pgsql and mysql
Potlatch	?	?}	?	*.osm to flash
Splitter	ssz	GPSBabel	GPSBabel	.osm to *.img
Traceosm	?	GPSBabel	GPSBabel

To me, NONE of these entries are data formats, they're programs. Eg, splitter is a program which splits up osm files. So Splitter isn't a data format, it doesn't have files with extension ssz, GPSBabel doesn't read or write those ssz files and it's got nothing directly to do with img files. So why is it here? Why are any of these here? JOSM isn't a data format, neither is Potlatch! If you want to list conversion tools like osm2gml, osm2shp and so on, why not use the Converter page which is seemingly just for this purpose? Eric2 13:45, 10 September 2009 (UTC)

Cleanup Request

Hi, we should refactor this page to become more usefull. My ideas:

• make this title shorter e.g. just Convert to get easier found
• merge related stub pages
• move related pages as subpages

The question is should be focus on tools(one tolle might convert multiple formats) or on formats(which is what the user usually looks for)? And how do we differ this page from Import? --!i! 09:15, 19 August 2010 (BST)

It should be a listed by format (as it is at moment) yes. It shouldn't include things like 'TIGER', 'AND', 'LINZ' really. There are converters written for these formats, but these are not widely used formats. It's not like people would randomly have files in this format for some reason. They're very specific data source formats, already covered under Imports. But the distinction might be tricky in some cases.

As will pretty much all pages listing stuff like this, it would nice if we created dedicated wiki pages for each of the things being listed.

-- Harry Wood 12:09, 19 August 2010 (BST)

So splitting up this list would make the problem smaller, right? What about Image formats, linking to Rendering gives more significant informations IMHO?--!i! 14:09, 19 August 2010 (BST)

What do you say Harry, would it be wise to rename this page to Convert and move the linked tutorial to somewhat like Convert/DXF?

Could move this page to Convert yes. Or leave it as it is. The current 'Convert' page looks a bit messy though. Maybe that should redirect here.

I'm not keen on "Convert/DXF" as page name. Sub-pages bad. Keep the page naming structure simple and flat. I prefer just "DXF format". This could then describe the file format before going on to describe the GRASS approach to converting it.

-- Harry Wood 16:00, 20 August 2010 (BST)

I understand keeping flat structures but subpages present the users ways to go up in the page hierarchy(upper left corner) which is very cool in my eyes and help externals to get an better orientation? Yes current Convert is just an redirect cause I didn't reviewed this page ;) --!i! 17:53, 20 August 2010 (BST)

No no I mean a #REDIRECT. I've done it. Now we could do it the other way round if we prefer, but I think that's OK as is.

If we wanted subpages too, then it would be important for this to move to the shorter page name. But we don't want subpages. Honestly we don't.

The subpages rant: (since I cant' remember where I had this before)

Subpages are one of those little bits of complexity which seem like a good idea on the face of it, and satisfy our desire to pigeon-hole information hierarchically, but further down the line we hit problems which could have been avoided by sticking to the flat naming structure which a wiki naturally follows.

To take this example, the DXF file format is actually related to "AutoCAD" software. With subpages then we hit a dilemma. We pigeon-holed the page at "Convert/DXF" whereas someone else wants to put it at "AutoCAD/DXF" (or even "Software/AutoCAD/DXF" if we're really going subpage crazy). So maybe we end up with a redirect, but whatever we do to workaround that, we've ended up with a slightly messy situation, and lots of page names with slashes in them. Not user-friendly particularly for a wiki newbie trying to understand how to link to a page. Subpages feel comfortable until you realise that information and knowledge rarely fits a simple hierarchy like that. It imposes rigidity on a wiki system which could otherwise be simple and loose and free. </philosophy>

OK so you're still thinking hierarchically? Do the heirachy anyway, but do it within the linking structure of the page content itself. e.g. Make sure that all file format pages link back to the 'Convert' page. Also have lots of hierarchical fun with wiki categories, just not in the wiki page names.

-- Harry Wood 18:37, 20 August 2010 (BST)

It's not a problem to do so Harry. I wanted to know the pros/cons. For my pages I would prever subpages and redirects but of course here a lot of people might interact. I will check the related pages and add backlinks :) --!i! 21:40, 20 August 2010 (BST)