[OSM-dev] c-programmer at your command

[Artem Pavlenko]

On 8 Feb 2008, at 11:54, SteveC wrote:

> I agree OSM in OGR is good but doesn't osm2pgsql -> OGR -> anything
> also work?
>

Of course, it does.


> 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