[OSM-dev] osm2psql .style file parameters/values

[mick]

On Tue, 10 Jul 2012 08:48:38 +0200
Frederik Ramm <frederik at remote.org> wrote:

> Hi,
> 
> On 07/10/12 03:54, mick wrote:
> > What other values can be used in each column? I would like to use a
> > logical data type for items like bridge, tunnel, oneway, ... and
> > small int for maxspeed, lanes, layers, ...
> 
> If you want a ready-made software that gives you more control over the 
> database structure than osm2pgsql offers, I suggest you have a look at 
> imposm (Python). If you want a solid programmer's framework for your own 
> OSM parsing and processing, I suggest you use osmium (C++).

osm2pgsql does a decent job as far as _I_ can use it, the style file looks to me like it should be able to refine things more with different data types, eg. boolean, short int, int, long int, float,...

Unfortunately I am unable to twist my mind around object-oriented type syntax but have an almost working knowledge of C, with help from snippets and other examples to hack at. GTK I find a challenge since the removed the C code generation feature from glade.

Looking at the easy to find descriptions and features of OSM I was starting to believe I was the only person trying to manipulate the data in these kinds of ways.
> 
> > Another useful feature would be to scan the .osm file for all tags
> > used and the other tags they are used with.
> 
> taginfo.openstreetmap.org does that on a world-wide basis but the 
> software is available for installing locally so you could run taginfo 
> for your area of interest only.

I'll give taginfo a closer look later. I have been using 
"cat mymap.osm | grep key > taglist" to help see what keys have been used in order to strip out key=value set I don't need but it doesn't get me all the way
> 
> > I am in the very early stages of a C program (using GTK for the gui)
> > with the eventual goal of allowing output as database input or
> > conversion to GIS formats. I'm stuck with some of the interface code
> > ATM.
> 
> You'll probably get stuck with other things later - it is not as easy as 
> one might think; you'll want pbf support, proper multipolygon handling, 
> and other things that cost time to implement. The aforementioned 
> software takes some of that burden away.

I'm certain to get stuck on many things as time passes. I have no delusions about it being any where near easy but if it was easy I wouldn't learn anything. 

Thanks Frederik, you have given me useful help.