[OSGeo-Discuss] Shapefile lacking SRS information

Andrew Turner ajturner at highearthorbit.com
Thu Sep 4 06:08:34 PDT 2008

Wow - great project. From my understanding - the most powerful aspect
here is that it's too easy for external metadata to be lost or
disassociated in archives. So merely having tags along-side an asset
(e.g. photo) means that if the photo is stored independent of the HTML
tags, then all is lost. By storing the metadata *in* the asset itself,
it means they are permanently linked (unless passed through bad

GeoCommons has all of the OSM data available as Shapefiles (and CSV & KML):

and there is a German FTP site with similar as shapefiles.

As for tools, I highly recommend the open-source ExifTool (perl)
library by Phil Harvey:

It is the core of most of the open and commercial geotagging software
out there. It is simple to wrap this in any script to geotag sets of

What I would then recommend is a simple "bundle" that is archived of
the tools needed to both geotag, and then mine/visualize any set of
photos. This would include a folder of:
 - exiftool
 - script for loading in folders of images and GPX/KML files
corresponding to photos
 - script for mining folders of images and dumping out as KML
 - OpenLayers & index.html for viewing a folder of images or loading in the KML

What you then have is a Time Capsule system for any images. :)

And re: Flickr et al. they are super great tools, and are archived -
and most importantly have API's for pulling out all of your stored

On Thu, Sep 4, 2008 at 6:08 AM, Kjell Are Refsvik
<kjell.a.refsvik at hiof.no> wrote:
> Den 3. sep.. 2008 kl. 19.34 skrev Andrew Turner:
>> You have a couple of options - one would be to just rasterize and
>> register/geo-rectify the image and then trace or use as a basemap.
>> Curiously, what is your goal with this data? Can you instead use other
>> base maps such as OpenStreetMap (either as vector or rendered tiles)?
> Oh, yes. I would love to use OSM vector data, but first let me tell you a
> little bit more about my project.
> My thesis are trying to address the current technical challenges and
> opportunities we experience relating to digital photographs and I have
> documented numerous of both. While for the most part a study of literature -
> my thesis also ends with a small software project where I will try to
> suggest a method (and associated tools) for presenting and sharing digital
> images that hopefully will do 3 things
> 1:Focus on the importance and existence of embedded metadata inside
> image-files so that more people can start using them,
> 2:The importance of the capture and use of context in general and more
> specifically location (as in the stuff grabbed by a GPS and ingested in
> Photos as lon/lat/alt/datum) as many people find location to be key to data
> like photographs, and
> 3: presenting it all in ways that makes it likely to survive for a long
> time.
> Supported by the fact that the National Library currently does its best to
> harvest the entire .no domain 2 times a year, I want to make a web-album
> software that writes standards-compliant HTML/CSS code, and also embeds maps
> of where they are taken into the album. This is a fairly recent sketch:
> http://www.ia-stud.hiof.no/~kjellare/misc/20080902_programming_goal.jpg
> The idea is that a user would use my script to generate a web-album from a
> group of JPEGs - hopefully geotagged and ready to be accessible - hopefully
> for a long time. Once put online (on a .no domain site) and harvested by the
> Nation Library, Its likelyhood of ever being completely lost should be
> significantly reduced, containing everything (images, thumbs,
> overview/detailed maps and code) it needs to work.
> Many people are using mash-ups and data from sources like GoogleMaps to do
> the same thing today - but my claim is that such a solution is not very
> likely to be stable in the long run as online services have a relatively
> short life-span and will eventually move, change or die. But solutions like
> Flickr does all this today and includes even maps, you might say. True - but
> online archiving solutions like the Internet Archive/WayBackMachine has
> shown that large complex online services is hard to archive and its size may
> also be a challenge for archiving solutions out there. Wanting to control my
> own data and make it easy to move it around to meet future needs have made
> me to come up with this alternative solution.
> In my efforts to complete this project, I have wanted to use platforms,
> software and data that are open sourced and/or freely available to ensure
> that it can easily be moved, changed, and/or freely developed further as
> users see fit. I am open to to any suggestions in terms of tools and data
> sources, but have for now used the 22 year old gnuplot sofware and the
> equally old (or even more?) UNIX platform to present my solution. In my
> opinion, these choices as tried and tested software/platforms and is as
> likely to survive for the next decades as any other. With its open strategy
> and fairly well documented command-set, UNIX itself could be seen as a
> development environment. It should be relatively easy for other people with
> only rudimentary programming skills (like myself) to open up my script and
> use or modify it and no compilation is necessary to run it, even further
> reducing complexity.
> My initial thought was to try to extract data from OpenStreetMap, but
> failing to do so, I had to opt for data from the Norwegian Mapping and
> Cadastre Authority (www.statkart.no). Having very little knowledge about
> geodata going into this, I will at this point have to limit my ambitions and
> proceed with the data I have. Having access to a open data source would have
> been and nice touch though, and made the map data source fit in very well
> with my other open technology-choices in this project. However - being on a
> fairly tight schedule, I think I have to opt for the second best thing at
> this point, and file the desire for open geodata-source under "Future
> works".
> Currently I am at the stage where I have converted a shapefile containing
> Norwegian municipalities to a basic text-file that gnuplot can draw:
> ...
> 10.460277557373047     60.025833129882812
> 10.472221374511719     60.025833129882812
> 10.487220764160156     60.020828247070312
> #Buskerud
> 8.190235137939453     61.079093933105469
> 8.203887939453125     61.093887329101562
> 8.212221145629883     61.100273132324219
> 8.273332595825195     61.074996948242188
> ...
> but I am looking for ways to add a better map with more resolution and
> features to improve the user experience. Having located a more detailed
> shapefile from a friend, (the request you got), I realized that the file was
> lacking information about SRS and that I needed this information to be able
> to convert the data to lon/lat/wgs84 (so that the map can be plotted in the
> same reference system as the images):
> http://www.ia-stud.hiof.no/~kjellare/misc/20080903_GeoConverter.png
> Any information helpful to the conversion of the shapefile to a
> lon/lat/wgs84 SRS would be greatly appreciated. I would also love to get
> some feedback on possible scenarios and methods of extracting what I need
> (i.e. coastline, counties, primary and secondary roads, footpaths,
> rivers/lakes and railroads) and turning it into open data files that can be
> openly converted and plotted using gnuplot.
> A current screenshot of the maps that are plotted can be found here:
> http://www.ia-stud.hiof.no/~kjellare/misc/20080903_makemap2.png
> ...and the script itself as of today is here:
> http://www.ia-stud.hiof.no/~kjellare/misc/20080903_makemap2.sh
> Sincerely,
> Kjell Are Refsvik
> Graduate Student, Information Technology
> Faculty of Computer Sciences
> Østfold University College, Norway
> email: kjell.a.refsvik at hiof.no
> mobile: +47 405 50 454
>> On Tue, Sep 2, 2008 at 3:39 AM, Rafal Wawer
>> <Rafal.Wawer at sadl.kuleuven.be> wrote:
>>> Dear Kjell,
>>> I am not an expert with GRASS, but form what I see in your e-mail, the
>>> shapefile itself (its geometry) seem to be OK. It si just lacking the SRS
>>> informaton.
>>> In Quantum GIS often (always?) happens, that the program does not read
>>> the
>>> ESRI WKT from *.prj file, hence you have to read it yourself and find the
>>> corresponding EPSG code on http://spatial-reference.org . Then you define
>>> it
>>> within layer's properties and that's it. I bet, there is similiar
>>> procedure
>>> in GRASS.
>>> Hope this helps a bit.
>>> Best regards:
>>> RAf
>>> Dr. Rafal Wawer
>>> K.U.Leuven
>>> R&D Division SADL (Spatial Application Division)
>>> Celestijnenlaan 200e bus 2224
>>> BE-3001 Leuven-Heverlee
>>> Belgium
>>> tel. 0032 16 329731
>>> ----- Original Message ----- From: "Kjell Are Refsvik"
>>> <kjell.a.refsvik at hiof.no>
>>> To: "OSGeo Discussions" <discuss at lists.osgeo.org>
>>> Sent: Monday, September 01, 2008 5:51 PM
>>> Subject: [OSGeo-Discuss] Shapefile lacking SRS information
>>> Hi,
>>> We communicated briefly this summer on issues relating to the
>>> conversion and creation of geodata. Looking through the emails from
>>> earlier this summer, I am very thankful for the time you spent, and
>>> hope that I am not intruding by asking one more:
>>> My status is that I am progressing to the point where I should be able
>>> to draw my own maps and have them included (mashed) with my web albums
>>> for photos soon.
>>> I am using UNIX shell-scripts to draw the maps I need based on a
>>> shapefile converted to .csv and geodata extracted from my photos:
>>> http://www.ia-stud.hiof.no/~kjellare/misc/20080829_gnuplot_status.png
>>> Trying to get hold of better maps, I have been trying to get some old
>>> shapefiles to work, but without success. They appear to have lost
>>> their Spacial Reference System:
>>> http://www.ia-stud.hiof.no/~kjellare/misc/20080901_SRS.png
>>> ...and I was just wondering - is it possible to repair them?
>>> Best regards,
>>> Kjell Are Refsvik
>>> -----
>>> Graduate Student, Information Technology
>>> Faculty of Computer Sciences
>>> Østfold University College, Norway
>>> email: kjell.a.refsvik at hiof.no
>>> mobile: +47 405 50 454
>>> _______________________________________________
>>> Discuss mailing list
>>> Discuss at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/discuss
>>> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>>> _______________________________________________
>>> Discuss mailing list
>>> Discuss at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/discuss
>> _______________________________________________
>> Discuss mailing list
>> Discuss at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/discuss
> Kjell Are Refsvik
> -----
> Mastergradsstudent, Informasjonsteknologi
> Avdeling for Informasjonsteknologi
> Høgskolen i Østfold
> e-post: kjell.a.refsvik at hiof.no
> mobil: +47 405 50 454

Andrew Turner
mobile: 248.982.3609
andrew at mapufacture.com

http://mapufacture.com Helping build the Geospatial Web
Introduction to Neogeography - http://oreilly.com/catalog/neogeography

More information about the Discuss mailing list