Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Trouble importing Shapefile

Anonymous
2012-10-29
2013-06-05

  • Anonymous
    2012-10-29

    Hi,

    I am trying to import an ESRI shape file (.SHP) depicting the area of Munich, Germany into OpenJUMP. The shapefile contains LineString objects which are described via WGS-84 latitude/longitude coordinates. There is also a .PRJ file describing the coordinate system using this WKT string:

    GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID],PRIMEM,UNIT]

    This WKT string should refer to the EPSG 4326 coordinate system, as it is described here:

    http://www.spatialreference.org/ref/epsg/4326/

    Appearently, OpenJUMP has build-in support for WGS-84 coordinates (as defined in class com.vividsolutions.jump.coordsys.impl.PredefinedCoordinateSystems -> GEOGRAPHICS_WGS_84).

    Unfortunately, while OpenJUMP successfully imports the file without an error, the scale seems to be completely messed up. A region spanning several kilometers is scaled in such a way that it spans several millimeters. If have so far not found a way to fix this. However, if I import another shapefile of the same region which contains values referring to a Lambert conformal conic projection, the scale seems to work.

    Does anyone have an idea how to get a correct scaling? Actually, I am not sure if the Shapefile Reader of OpenJUMP even considers the .PRJ file at all. I also had no luck in forcing the CoordinateSystem instance to be the "Geographics" one defined in the CoordinateSystemRegistry (in com.vividsolutions.jump.io.datasource.DataSource.installCoordinateSystem()).

     
  • mentaer
    mentaer
    2012-10-29

    In general, OJ does not care about your projection. It just keeps data as is. So I am surprised it works with Lambert data.
    You would need to load the data with you geographic coordinates, as you did, and then transform them with an additional plugin, see here:

    http://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=CTS_Extension

    You can also transform your data with another GIS before-hand, e.g. Quantum GIS, which even offers on-the-fly re-projection.

    hope this helps
    stefan

     

  • Anonymous
    2012-10-31

    Thanks! The CTS Extension worked. However, I had to first convert to WGS-84 and then to Gauss-Krüger Zone 4. I still have no idea why this process corrects the scaling, though. It should be noted that Quantum GIS was able to import the shapefile with the right scaling without further reprojection. The same applies to ArcGIS Explorer. So maybe there is still a bug in OpenJUMP. WGS-84 doesn't define a projection, thus importing shapefiles with plain latitude/longitude WGS-84 shouldn't cause trouble with the scaling.

    About the Lambert data, this was not entirely correctly imported. I observed some kind of distortion which is probably caused by the projection. Not a big deal though since if you have Lambert projected data, you can reproject it first using Quantum GIS, as you described.

    Regards,
    Andreas

     
  • As Stefan explained, OpenJUMP don't care about projection. PRJ file is simply ignored.
    Moreover, it will consider that imported data unit is the "meter", which, in your case, is wrong.
    With your data, each degree is "interpreted" by OpenJUMP as a "meter".
    This is what appeared to you as a scaling problem (and which, indeed, is much more than a scaling problem!).

    CTS makes it possible to transform geographic coordinates into projected coordinates (which unit is generally the meter)
    I have no experience with CTS but my bet is the two steps you had to do are :
    - let CTS know that your data use the WGS 84 geograhic system (which is needed to reproject it correctly)
    (this step would not be needed if OpenJUMP had read the PRJ)
    - let CTS transform your data from geographic WGS 84 to the desired projection (in your case, Gauss-Kruger)

    On the other hand, QGis or ArcGIS read the PRJ, know that your data uses Geographic WGS 84 (in degree),
    and if you ask to display data in Gauss-Kruger projection, automatically reproject the data.

    Hope it makes the problem you have faced clearer.

    Michaël