[OSM-dev] c-programmer at your command

Artem Pavlenko artem.mapnik at googlemail.com
Fri Feb 8 12:36:03 GMT 2008


On 8 Feb 2008, at 12:29, Nick Black wrote:

> On Feb 8, 2008 11:54 AM, SteveC <steve at asklater.com> wrote:
>> I agree OSM in OGR is good but doesn't osm2pgsql -> OGR -> anything
>> also work?
>
> Not really - as osm2pgsql needs PostGIS which is a bitch to install

Hmm..  apt-get install

> &
> it relies on a defined attribute set, which is optimised for
> rendering.

True. It would be great to improve osm2pgsql to support user defined  
schemas.
Artem
>
>
>>
>>
>> On 7 Feb 2008, at 23:50, Milo van der Linden wrote:
>>
>>> Hello Hendri (and list)
>>>
>>> There is a piece of GIS-translation Open Source software that is
>>> currently head of the horde.
>>> It mainly consists of two pieces:
>>> - OGR; for translating from an to all kind of GIS formats (including
>>> shape files and postGIS)<http://www.gdal.org/ogr/>
>>> - GDAL; for raster files warping, georeferencing and
>>> translating.<http://www.gdal.org/>
>>>
>>> OGR/GDAL is solid and extremely active. Their community is even  
>>> larger
>>> then the OSM community consisting mostly of GIS professionals.
>>> I have been posting messages to the GDAL/OGR development team to get
>>> OSM
>>> as a recognized datasource integrated in their software.
>>>
>>> Why?
>>>
>>> Mainly because adding OSM data format to OGR would open up the vault
>>> of
>>> ALL available GIS formats to get your OSM data into!
>>>
>>> I know there is an OSM2PostGIS and attempts have been made to create
>>> stable OSM2SHP conversion software, but adding it to OGR would realy
>>> speed up things.
>>>
>>> So, if you are well at home in C and C++, maybe you would like to
>>> consider joining the OGR/GDAL team to get OSM as a solid and  
>>> reliable
>>> data adapter?
>>>
>>>
>>>
>>> My knowledge on OGR is excelent as a user, not as a programmer.  
>>> But my
>>> bet would be on OGR when I would have the skills to join them.
>>>
>>>
>>> Hendrik Siedelmann schreef:
>>>> Hello,
>>>>
>>>> This Project is great, and so I thought I'd like to help. As I  
>>>> do not
>>>> own a GPS-device the only possibility is to lend my programming
>>>> skills
>>>> in the c language.
>>>>
>>>> For now I already have some (ugly) code that parses an osm file and
>>>> loads the ways into an r-tree, to allow fast lookup of areas. I  
>>>> also
>>>> added some first svg export.
>>>>
>>>> But befor I begin developing something that someone else has  
>>>> already
>>>> done, what Is needed the most:
>>>> - fast Database as a backend for osm-based applications
>>>>
>>> postGIS, definitly!
>>>> - unified osm to svg converter
>>>>
>>> Why only stick with svg when OGR opens up a whole lot of data  
>>> formats
>>> for you?<http://www.gdal.org/ogr/ogr_formats.html>
>>>> - ... something else I could do?
>>>>
>>> I think that routing is the way to enhance OSM for the near future.
>>> There is an implementation of Dijkstra algorithm for postGIS
>>> <http://www.cartoweb.org/cwiki/PgdijkstraWin32>
>>> But it would be good to set up a good algorithm that is more general
>>> and
>>> based on binary files rather then database tables, thus optimizing
>>> data
>>> access.
>>> People are already working on using OSM with qGIS for routing
>>> <http://blog.qgis.org/?q=node/73> check it out!
>>>> Also I have (of Course ;) ) some notes to make his Project even
>>>> better:
>>>>
>>>> Why do nodes and ways have to be split? This makes working with osm
>>>> data pretty complicated, as it requieres a database to work  
>>>> with, and
>>>> just to get the data of one way requires many node lookups,  
>>>> which is
>>>> slow, especially if osm data would be use on handheld devices.
>>>> Couldn't nodes simply be identified by their coordinates? This  
>>>> would
>>>> also require less memory.
>>>>
>>> This is one of the main issues in my opinion too. Therefor good
>>> translation software needs to be made to get OSM data into a routing
>>> optimized binary file structure with r-tree functionality?
>>>> Bezier curves. They are currently added via post-processing, which
>>>> means suboptimal results, the mapper has little influence on the
>>>> appearence and there are basically no memory savings. Instead of
>>>> adding a rounding tag which does not solve most of these issues,  
>>>> what
>>>> about deriving the bezier curves from original data?
>>>> Gps-Tracks a series of points, and propably also most of the other
>>>> sources of map data? (I don't know). So if the mapper simply
>>>> specifies
>>>> that the points between two points in the track form a way, then we
>>>> could derive static sets of (bezier-) map data. And route
>>>> calculations
>>>> and so on can be done on the original simple data.
>>>>
>>> Beziers are a major problem in ALL gis file formats. So if you  
>>> come up
>>> with a solution there is a great future for you.
>>>> Well thats it for now.
>>>> Here is the database I coded for now (better dont't look at  
>>>> it ;) ):
>>>> http://minimi.dyndns.org/mkdb33.c.bz2
>>>> When started it reads from a file "map_p" in the working dir, which
>>>> could be a pipe from a decompressor. The program writes data to
>>>> "/tmp/osm/" so be sure to create this directory!
>>>> After the import is finished, the Program will ask for
>>>> latitude/longitude pairs and then dump a svg file named "place.svg"
>>>> in
>>>> the working dir.
>>>> The program is slow at the moment, so better test with a small
>>>> dataset. I chose ther Germany extract of the planet dump.
>>>>
>>>> Here is such an svg dum:
>>>> http://minimi.dyndns.org/48.78x9.12.svg.bz2
>>>>
>>>> hendrik
>>>>
>>>>
>>> Good luck and welcome to the team!
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev at openstreetmap.org
>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev at openstreetmap.org
>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>>>
>>
>> have fun,
>>
>> SteveC | steve at asklater.com | http://www.asklater.com/steve/
>>
>>
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev at openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>>
>
>
>
> -- 
> Nick Black
> --------------------------------
> http://www.blacksworld.net
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev





More information about the dev mailing list