[OSGeo-Discuss] Shapefile lacking SRS information

Rafal Wawer Rafal.Wawer at sadl.kuleuven.be
Thu Sep 4 03:26:04 PDT 2008


Dear Kjell,
1. Is there any *.prj file attached to the shapefile?
2. If not - what are the common SRS systems used in Norway? Can you find any 
data in those Norwegian SRSs? If you find the data load it and check whether 
it overlaps with your shapefile. If you find one that does, you will know 
the right SRS. Then you can either write a *.prj file yourself or give the 
EPSG code of the SRS (both to be found in http://spatial-rference.org ) 
within the GeoConverter.

Regarding:
"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."

You have to be very carefull before you make the derivatives of that 
shapefile public. Is that source public? Who is the owner of the data? What 
are the conditions of use?

Kind 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>; "Andrew Turner" 
<ajturner at highearthorbit.com>
Sent: Thursday, September 04, 2008 12:08 PM
Subject: Re: [OSGeo-Discuss] Shapefile lacking SRS information



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

_______________________________________________
Discuss mailing list
Discuss at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss



Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm




More information about the Discuss mailing list