no it is not necessary to have a source system as long as you have points in your dataset that have coordinates in the source system and the target system if you use a transformation that operates in the plane (such as an affine transformation)

However, what is of advantage is if those points are surrounding all other points (i.e. all data lying in the (convex) hull formed by of those points).

oh.. now I also remember the 4th point what is important: What extension (i.e. in km) has your dataset. if it is a couple of 10's of km I wouldn't use any planar affine-transformation . But what yould work is a rubbersheeting-like menthod with a lots of points in both Systems, i.e. the Warping Method in OpenJUMP that creates triangles and transforms data within each triangle in a differnt way if I remember correctly (I am not sure what Warping is called now in OJ 1.3).

stefan

Kurt Heston schrieb:
Brent,

Great suggestions, thanks!

You said, "The key to this working is knowing the coordinate reference
system of your source data" and I'm a little confused.  Are you assuming
there must be an actual place on earth this data is referenced to?  Just
to clarify: there is none, it's not that I can't find it.  The features
were created just so they would look good on the screen, not with any
reference to actual coordinates.

Does this clarification change anything you suggested?

Thanks again!


Brent Wood wrote:
Hi Kurt,

If you can work out what the projection system is for your data, then Proj.4 
can do the conversion for you.

Note that it is likely to be easier to use ogr2ogr (part of GDAL) as this can 
use the proj.4 libraries to reproject data, but can also read/write shapefiles 
so you could generate reprojected shapefiles directly from your original 
shapefile.

The key to thi working is knowing the coordinate reference system of your 
source data.

If this infomation is not available, then some sort of manual coordinate 
transformation may be possible, based on your suggested approach of working 
from visually determined points, but I'd use this approach as a last resort, 
especially if any sort of accuracy is required.

see: http://www.gdal.org/



Cheers,

Brent Wood
Brent Wood
DBA/GIS consultant
NIWA, Wellington
New Zealand
Kurt Heston <[email protected]> 05/11/09 10:22 AM >>>
I've inherited a set of shape files that are not georeferenced.  The
upper left corner of the extent is on 0/0 lat/lon.  So, when I try to
view them after translating to KML, for example, they show up in the
middle of the Atlantic Ocean.

Is there any way in OpenJump that I can fix them?  There's about a 130k
polygons involved with lots of attributes that I'd like to forego
re-creating if I can.

If I use a survey-grade GPS or Google Earth to match a bunch of points
in these shapefiles to their true locations on Earth, can something
move/stretch/skew/scale them to their earthly positions?  This HAS to
have been done at some point with all the non-geo CAD stuff that existed
b4 geo-spatial tooling took hold, right?

I'm hoping there's a tool I've missed (in much Googling) that I can use
to correlate the two.  I'm guessing that if such a tool is available,
it's going to take A LOT of point matches to fix the files, but that
scares me less than re-creating the data in its entirety.

Can anyone send me in the right direction here?
_______________________________________________
jump-users mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jump-users

NIWA is the trading name of the National Institute of Water & Atmospheric 
Research Ltd.

_______________________________________________
jump-users mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jump-users


_______________________________________________
jump-users mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jump-users

Reply via email to