I have a shapefile that I imported into R using readOGR from the rgdal
package. I do a little bit of work with it, like adding attribute information, etc, then export it as an ESRI shapefile again, with a new name. However, when I bring both the original and new shapefile into ArcGIS, it tells me that the CRS do not match. So, noting that all the projection parameters remain the same, but the projection and coordinate system names are different, and the datum name is dropped, my questions are: 1. Is the second CRS the same as the first? 2. If so, why did the names change, and why does ArcGIS no longer recognize it as the same? 3. If not, how did it get changed? 4. Can the proj4string be modified to be more specific, and if so, why did readOGR not already do this to preserve all the information? I can use the new shapefiles just fine and readOGR interprets them as identical, but it is a bit vexing that ArcGIS does not. And, I could of course define it again in ArcGIS, but part of the motivation to work in R is to obviate the need to point and click for many files. I appreciate any insights or enlightenment. Thanks, Glenn Here is the original projection information from ArcGIS: Projected Coordinate System: NAD_1983_HARN_Transverse_Mercator Projection: Transverse_Mercator False_Easting: 520000.00000000 False_Northing: 4480000.00000000 Central_Meridian: 90.00000000 Scale_Factor: 0.99960000 Latitude_Of_Origin: 0.00000000 Linear Unit: Meter Geographic Coordinate System: GCS_North_American_1983_HARN Datum: D_North_American_1983_HARN Prime Meridian: Greenwich Angular Unit: Degree Here is the proj4string from R, which also agrees with the proj4string given for this projection at www.spatialreference.org for epsg:3071 and also for SRORG:7396. +proj=tmerc +lat_0=0 +lon_0=90 +k=0.9996 +x_0=520000 +y_0=4480000 +ellps=GRS80 +units=m +no_defs When I use writeOGR to export the SpatialPolygonsDataFrame with the above proj4string, then bring it back into ArcGIS, the projection information is given as the following, and is no longer recognized as identical to the original. Projected Coordinate System: Transverse_Mercator Projection: Transverse_Mercator false_easting: 520000.00000000 false_northing: 4480000.00000000 central_meridian: 90.00000000 scale_factor: 0.99960000 latitude_of_origin: 0.00000000 Linear Unit: Meter Geographic Coordinate System: GCS_GRS 1980(IUGG, 1980) Datum: D_unknown Prime Meridian: Greenwich Angular Unit: Degree [[alternative HTML version deleted]] _______________________________________________ RsigGeo mailing list [hidden email] https://stat.ethz.ch/mailman/listinfo/rsiggeo 
Glen,
Roundtripping projection information can be tricky, in part because the normalization routines vary between different stacks, and what counts as the same form is also implementation dependent. In this case (roundtripping with ArcGIS), you may be better off using the arcgisbinding package [1], which can do the conversion to and from ArcGIS native data types (including some that aren't available via OGR/GDAL). It's easy enough to install [2], and also lets you build Geoprocessing tools which speak directly to R. I imagine there's also a pure R solution to the normalization, but it would likely have side effects for existing packages, and may not be easily solved. If you know that your data is fine and want a simple solution, you could also just overwrite the new shapefile’s .prj file with a copy of the original. Cheers, Shaun 1. https://urldefense.proofpoint.com/v2/url?u=https3A__r2Darcgis.github.io_assets_arcgisbinding.pdf&d=DwIGaQ&c=n6cguzQvX_tUIrZOS_4Og&r=fCPRb7QXvd5bnO9gIJHCiX852SVUtyYXxtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W0Tm65yvo7NmjLw&s=pIBxR3icnDLcn639TzBc0mkXy6Tv7G9Ip7xcWSAMweU&e= 2. https://urldefense.proofpoint.com/v2/url?u=https3A__github.com_R2DArcGIS_r2Dbridge2Dinstall&d=DwIGaQ&c=n6cguzQvX_tUIrZOS_4Og&r=fCPRb7QXvd5bnO9gIJHCiX852SVUtyYXxtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W0Tm65yvo7NmjLw&s=JADt055JJUuCG1eltd7N9o5f_fu_geqGlnzO62SGtGM&e= On 6/14/17, 9:35 AM, "RsigGeo on behalf of Glenn Stauffer" <[hidden email] on behalf of [hidden email]> wrote: I have a shapefile that I imported into R using readOGR from the rgdal package. I do a little bit of work with it, like adding attribute information, etc, then export it as an ESRI shapefile again, with a new name. However, when I bring both the original and new shapefile into ArcGIS, it tells me that the CRS do not match. So, noting that all the projection parameters remain the same, but the projection and coordinate system names are different, and the datum name is dropped, my questions are: 1. Is the second CRS the same as the first? 2. If so, why did the names change, and why does ArcGIS no longer recognize it as the same? 3. If not, how did it get changed? 4. Can the proj4string be modified to be more specific, and if so, why did readOGR not already do this to preserve all the information? I can use the new shapefiles just fine and readOGR interprets them as identical, but it is a bit vexing that ArcGIS does not. And, I could of course define it again in ArcGIS, but part of the motivation to work in R is to obviate the need to point and click for many files. I appreciate any insights or enlightenment. Thanks, Glenn Here is the original projection information from ArcGIS: Projected Coordinate System: NAD_1983_HARN_Transverse_Mercator Projection: Transverse_Mercator False_Easting: 520000.00000000 False_Northing: 4480000.00000000 Central_Meridian: 90.00000000 Scale_Factor: 0.99960000 Latitude_Of_Origin: 0.00000000 Linear Unit: Meter Geographic Coordinate System: GCS_North_American_1983_HARN Datum: D_North_American_1983_HARN Prime Meridian: Greenwich Angular Unit: Degree Here is the proj4string from R, which also agrees with the proj4string given for this projection at www.spatialreference.org for epsg:3071 and also for SRORG:7396. +proj=tmerc +lat_0=0 +lon_0=90 +k=0.9996 +x_0=520000 +y_0=4480000 +ellps=GRS80 +units=m +no_defs When I use writeOGR to export the SpatialPolygonsDataFrame with the above proj4string, then bring it back into ArcGIS, the projection information is given as the following, and is no longer recognized as identical to the original. Projected Coordinate System: Transverse_Mercator Projection: Transverse_Mercator false_easting: 520000.00000000 false_northing: 4480000.00000000 central_meridian: 90.00000000 scale_factor: 0.99960000 latitude_of_origin: 0.00000000 Linear Unit: Meter Geographic Coordinate System: GCS_GRS 1980(IUGG, 1980) Datum: D_unknown Prime Meridian: Greenwich Angular Unit: Degree [[alternative HTML version deleted]] _______________________________________________ RsigGeo mailing list [hidden email] https://urldefense.proofpoint.com/v2/url?u=https3A__stat.ethz.ch_mailman_listinfo_r2Dsig2Dgeo&d=DwICAg&c=n6cguzQvX_tUIrZOS_4Og&r=YFaRLkcUCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=Ws5QzgjxjD1HGvdDia3XoimuEiDzcY4WhCLS905w0&s=gBdaQAI6IxVnnl8qdt_GTEeiM7f2_5dd15qzQOsQ_64&e= _______________________________________________ RsigGeo mailing list [hidden email] https://stat.ethz.ch/mailman/listinfo/rsiggeo 
Also relevant to this question is this discussion/issue:
https://github.com/edzer/sfr/issues/380 On 14/06/17 17:14, Shaun Walbridge wrote: > Glen, > > Roundtripping projection information can be tricky, in part because the > normalization routines vary between different stacks, and what counts > as the same form is also implementation dependent. In this case > (roundtripping with ArcGIS), you may be better off using the > arcgisbinding package [1], which can do the conversion to and from > ArcGIS native data types (including some that aren't available via > OGR/GDAL). It's easy enough to install [2], and also lets you build > Geoprocessing tools which speak directly to R. I imagine there's also a > pure R solution to the normalization, but it would likely have side > effects for existing packages, and may not be easily solved. > > If you know that your data is fine and want a simple solution, you could > also just overwrite the new shapefile’s .prj file with a copy of the > original. > > Cheers, > Shaun > > 1. https://urldefense.proofpoint.com/v2/url?u=https3A__r2Darcgis.github.io_assets_arcgisbinding.pdf&d=DwIGaQ&c=n6cguzQvX_tUIrZOS_4Og&r=fCPRb7QXvd5bnO9gIJHCiX852SVUtyYXxtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W0Tm65yvo7NmjLw&s=pIBxR3icnDLcn639TzBc0mkXy6Tv7G9Ip7xcWSAMweU&e= > 2. https://urldefense.proofpoint.com/v2/url?u=https3A__github.com_R2DArcGIS_r2Dbridge2Dinstall&d=DwIGaQ&c=n6cguzQvX_tUIrZOS_4Og&r=fCPRb7QXvd5bnO9gIJHCiX852SVUtyYXxtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W0Tm65yvo7NmjLw&s=JADt055JJUuCG1eltd7N9o5f_fu_geqGlnzO62SGtGM&e= > > On 6/14/17, 9:35 AM, "RsigGeo on behalf of Glenn Stauffer" <[hidden email] on behalf of [hidden email]> wrote: > > I have a shapefile that I imported into R using readOGR from the rgdal > package. I do a little bit of work with it, like adding attribute > information, etc, then export it as an ESRI shapefile again, with a new > name. However, when I bring both the original and new shapefile into ArcGIS, > it tells me that the CRS do not match. > > So, noting that all the projection parameters remain the same, but the > projection and coordinate system names are different, and the datum name is > dropped, my questions are: > > 1. Is the second CRS the same as the first? > 2. If so, why did the names change, and why does ArcGIS no longer > recognize it as the same? > 3. If not, how did it get changed? > 4. Can the proj4string be modified to be more specific, and if so, why > did readOGR not already do this to preserve all the information? > > I can use the new shapefiles just fine and readOGR interprets them as > identical, but it is a bit vexing that ArcGIS does not. And, I could of > course define it again in ArcGIS, but part of the motivation to work in R is > to obviate the need to point and click for many files. > > I appreciate any insights or enlightenment. > > Thanks, > > Glenn > > Here is the original projection information from ArcGIS: > > Projected Coordinate System: NAD_1983_HARN_Transverse_Mercator > > Projection: Transverse_Mercator > > False_Easting: 520000.00000000 > > False_Northing: 4480000.00000000 > > Central_Meridian: 90.00000000 > > Scale_Factor: 0.99960000 > > Latitude_Of_Origin: 0.00000000 > > Linear Unit: Meter > > > > Geographic Coordinate System: GCS_North_American_1983_HARN > > Datum: D_North_American_1983_HARN > > Prime Meridian: Greenwich > > Angular Unit: Degree > > Here is the proj4string from R, which also agrees with the proj4string given > for this projection at www.spatialreference.org for epsg:3071 and also for > SRORG:7396. > > +proj=tmerc +lat_0=0 +lon_0=90 +k=0.9996 +x_0=520000 +y_0=4480000 > +ellps=GRS80 +units=m +no_defs > > When I use writeOGR to export the SpatialPolygonsDataFrame with the above > proj4string, then bring it back into ArcGIS, the projection information is > given as the following, and is no longer recognized as identical to the > original. > > Projected Coordinate System: Transverse_Mercator > > Projection: Transverse_Mercator > > false_easting: 520000.00000000 > > false_northing: 4480000.00000000 > > central_meridian: 90.00000000 > > scale_factor: 0.99960000 > > latitude_of_origin: 0.00000000 > > Linear Unit: Meter > > > > Geographic Coordinate System: GCS_GRS 1980(IUGG, 1980) > > Datum: D_unknown > > Prime Meridian: Greenwich > > Angular Unit: Degree > > > > > > > [[alternative HTML version deleted]] > > _______________________________________________ > RsigGeo mailing list > [hidden email] > https://urldefense.proofpoint.com/v2/url?u=https3A__stat.ethz.ch_mailman_listinfo_r2Dsig2Dgeo&d=DwICAg&c=n6cguzQvX_tUIrZOS_4Og&r=YFaRLkcUCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=Ws5QzgjxjD1HGvdDia3XoimuEiDzcY4WhCLS905w0&s=gBdaQAI6IxVnnl8qdt_GTEeiM7f2_5dd15qzQOsQ_64&e= > > > > _______________________________________________ > RsigGeo mailing list > [hidden email] > https://stat.ethz.ch/mailman/listinfo/rsiggeo > Edzer Pebesma Institute for Geoinformatics (ifgi), University of Münster Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081 Journal of Statistical Software: http://www.jstatsoft.org/ Computers & Geosciences: http://elsevier.com/locate/cageo/ _______________________________________________ RsigGeo mailing list [hidden email] https://stat.ethz.ch/mailman/listinfo/rsiggeo signature.asc (484 bytes) Download Attachment 
In reply to this post by Shaun Walbridge
Thanks Shaun,
I have not gotten the arcgisbinding package to work yet, and will play around with it some more later. For now, overwriting the .prj file works just fine and does what I want, but it seems like a lessthansatisfactory general solution. Glenn Original Message From: Shaun Walbridge [mailto:[hidden email]] Sent: Wednesday, June 14, 2017 10:14 AM To: Glenn Stauffer; [hidden email] Subject: Re: [RsigGeo] proj4string read by readOGR doesn't seem to precisely specify source shapefile projection Glen, Roundtripping projection information can be tricky, in part because the normalization routines vary between different stacks, and what counts as the same form is also implementation dependent. In this case (roundtripping with ArcGIS), you may be better off using the arcgisbinding package [1], which can do the conversion to and from ArcGIS native data types (including some that aren't available via OGR/GDAL). It's easy enough to install [2], and also lets you build Geoprocessing tools which speak directly to R. I imagine there's also a pure R solution to the normalization, but it would likely have side effects for existing packages, and may not be easily solved. If you know that your data is fine and want a simple solution, you could also just overwrite the new shapefile’s .prj file with a copy of the original. Cheers, Shaun 1. https://urldefense.proofpoint.com/v2/url?u=https3A__r2Darcgis.github.io_assets_arcgisbinding.pdf&d=DwIGaQ&c=n6cguzQvX_tUIrZOS_4Og&r=5UpQjHXPqFUScg58BUIFe0V27sq0j0SU7iU72HpYMRE&m=_FSAFRAGaC_k8hnGwM32OZirmWVi4Y5JSgcMf6lcemc&s=_ZSX1hSgmnuhYzWoUo1N3o_6nKHXkyG4VwSmOB276M&e= 2. https://urldefense.proofpoint.com/v2/url?u=https3A__github.com_R2DArcGIS_r2Dbridge2Dinstall&d=DwIGaQ&c=n6cguzQvX_tUIrZOS_4Og&r=5UpQjHXPqFUScg58BUIFe0V27sq0j0SU7iU72HpYMRE&m=_FSAFRAGaC_k8hnGwM32OZirmWVi4Y5JSgcMf6lcemc&s=xV9M4ZmMdIeeGjFZaKaEtSQA4CAvcB0_UWCjmqUX0&e= On 6/14/17, 9:35 AM, "RsigGeo on behalf of Glenn Stauffer" <[hidden email] on behalf of [hidden email]> wrote: I have a shapefile that I imported into R using readOGR from the rgdal package. I do a little bit of work with it, like adding attribute information, etc, then export it as an ESRI shapefile again, with a new name. However, when I bring both the original and new shapefile into ArcGIS, it tells me that the CRS do not match. So, noting that all the projection parameters remain the same, but the projection and coordinate system names are different, and the datum name is dropped, my questions are: 1. Is the second CRS the same as the first? 2. If so, why did the names change, and why does ArcGIS no longer recognize it as the same? 3. If not, how did it get changed? 4. Can the proj4string be modified to be more specific, and if so, why did readOGR not already do this to preserve all the information? I can use the new shapefiles just fine and readOGR interprets them as identical, but it is a bit vexing that ArcGIS does not. And, I could of course define it again in ArcGIS, but part of the motivation to work in R is to obviate the need to point and click for many files. I appreciate any insights or enlightenment. Thanks, Glenn Here is the original projection information from ArcGIS: Projected Coordinate System: NAD_1983_HARN_Transverse_Mercator Projection: Transverse_Mercator False_Easting: 520000.00000000 False_Northing: 4480000.00000000 Central_Meridian: 90.00000000 Scale_Factor: 0.99960000 Latitude_Of_Origin: 0.00000000 Linear Unit: Meter Geographic Coordinate System: GCS_North_American_1983_HARN Datum: D_North_American_1983_HARN Prime Meridian: Greenwich Angular Unit: Degree Here is the proj4string from R, which also agrees with the proj4string given for this projection at www.spatialreference.org for epsg:3071 and also for SRORG:7396. +proj=tmerc +lat_0=0 +lon_0=90 +k=0.9996 +x_0=520000 +y_0=4480000 +ellps=GRS80 +units=m +no_defs When I use writeOGR to export the SpatialPolygonsDataFrame with the above proj4string, then bring it back into ArcGIS, the projection information is given as the following, and is no longer recognized as identical to the original. Projected Coordinate System: Transverse_Mercator Projection: Transverse_Mercator false_easting: 520000.00000000 false_northing: 4480000.00000000 central_meridian: 90.00000000 scale_factor: 0.99960000 latitude_of_origin: 0.00000000 Linear Unit: Meter Geographic Coordinate System: GCS_GRS 1980(IUGG, 1980) Datum: D_unknown Prime Meridian: Greenwich Angular Unit: Degree [[alternative HTML version deleted]] _______________________________________________ RsigGeo mailing list [hidden email] https://urldefense.proofpoint.com/v2/url?u=https3A__stat.ethz.ch_mailman_listinfo_r2Dsig2Dgeo&d=DwICAg&c=n6cguzQvX_tUIrZOS_4Og&r=YFaRLkcUCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=Ws5QzgjxjD1HGvdDia3XoimuEiDzcY4WhCLS905w0&s=gBdaQAI6IxVnnl8qdt_GTEeiM7f2_5dd15qzQOsQ_64&e= _______________________________________________ RsigGeo mailing list [hidden email] https://stat.ethz.ch/mailman/listinfo/rsiggeo 
In reply to this post by edzer
Thanks for the link. That does shed some light, but I'm not sure I entirely understand. The .prj file does not store the EPSG ID, but it looks like the shapefile properties does include that information. Furthermore, when I overwrite the .prj file as Shaun suggested, the properties of the associated shapefile now does show " WKID: 3071 Authority: EPSG " whereas it did not previously. But aside from that, I'm not sure why readOGR didn't identify the datum information in the first place. When I add "+datum=NAD83" to the proj4string, ArcGIS seems to accept it as the same CRS, even though the original datum was NAD83 HARN (which I don't know how to specify in R). But I am pretty new to this.... For now, overwriting the .prj with the desired one seems to work for me (and it is easy to do in a script).
Glenn Original Message From: RsigGeo [mailto:[hidden email]] On Behalf Of Edzer Pebesma Sent: Wednesday, June 14, 2017 11:12 AM To: [hidden email] Subject: Re: [RsigGeo] proj4string read by readOGR doesn't seem to precisely specify source shapefile projection Also relevant to this question is this discussion/issue: https://github.com/edzer/sfr/issues/380 On 14/06/17 17:14, Shaun Walbridge wrote: > Glen, > > Roundtripping projection information can be tricky, in part because > the normalization routines vary between different stacks, and what > counts as the same form is also implementation dependent. In this case > (roundtripping with ArcGIS), you may be better off using the > arcgisbinding package [1], which can do the conversion to and from > ArcGIS native data types (including some that aren't available via > OGR/GDAL). It's easy enough to install [2], and also lets you build > Geoprocessing tools which speak directly to R. I imagine there's also > a pure R solution to the normalization, but it would likely have side > effects for existing packages, and may not be easily solved. > > If you know that your data is fine and want a simple solution, you > could also just overwrite the new shapefile’s .prj file with a copy of > the original. > > Cheers, > Shaun > > 1. > https://urldefense.proofpoint.com/v2/url?u=https3A__r2Darcgis.github > .io_assets_arcgisbinding.pdf&d=DwIGaQ&c=n6cguzQvX_tUIrZOS_4Og&r=fCPRb > 7QXvd5bnO9gIJHCiX852SVUtyYXxtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W > 0Tm65yvo7NmjLw&s=pIBxR3icnDLcn639TzBc0mkXy6Tv7G9Ip7xcWSAMweU&e= > 2. > https://urldefense.proofpoint.com/v2/url?u=https3A__github.com_R2DAr > cGIS_r2Dbridge2Dinstall&d=DwIGaQ&c=n6cguzQvX_tUIrZOS_4Og&r=fCPRb7QX > vd5bnO9gIJHCiX852SVUtyYXxtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W0Tm > 65yvo7NmjLw&s=JADt055JJUuCG1eltd7N9o5f_fu_geqGlnzO62SGtGM&e= > > On 6/14/17, 9:35 AM, "RsigGeo on behalf of Glenn Stauffer" <[hidden email] on behalf of [hidden email]> wrote: > > I have a shapefile that I imported into R using readOGR from the rgdal > package. I do a little bit of work with it, like adding attribute > information, etc, then export it as an ESRI shapefile again, with a new > name. However, when I bring both the original and new shapefile into ArcGIS, > it tells me that the CRS do not match. > > So, noting that all the projection parameters remain the same, but the > projection and coordinate system names are different, and the datum name is > dropped, my questions are: > > 1. Is the second CRS the same as the first? > 2. If so, why did the names change, and why does ArcGIS no longer > recognize it as the same? > 3. If not, how did it get changed? > 4. Can the proj4string be modified to be more specific, and if so, why > did readOGR not already do this to preserve all the information? > > I can use the new shapefiles just fine and readOGR interprets them as > identical, but it is a bit vexing that ArcGIS does not. And, I could of > course define it again in ArcGIS, but part of the motivation to work in R is > to obviate the need to point and click for many files. > > I appreciate any insights or enlightenment. > > Thanks, > > Glenn > > Here is the original projection information from ArcGIS: > > Projected Coordinate System: NAD_1983_HARN_Transverse_Mercator > > Projection: Transverse_Mercator > > False_Easting: 520000.00000000 > > False_Northing: 4480000.00000000 > > Central_Meridian: 90.00000000 > > Scale_Factor: 0.99960000 > > Latitude_Of_Origin: 0.00000000 > > Linear Unit: Meter > > > > Geographic Coordinate System: GCS_North_American_1983_HARN > > Datum: D_North_American_1983_HARN > > Prime Meridian: Greenwich > > Angular Unit: Degree > > Here is the proj4string from R, which also agrees with the proj4string given > for this projection at www.spatialreference.org for epsg:3071 and also for > SRORG:7396. > > +proj=tmerc +lat_0=0 +lon_0=90 +k=0.9996 +x_0=520000 +y_0=4480000 > +ellps=GRS80 +units=m +no_defs > > When I use writeOGR to export the SpatialPolygonsDataFrame with the above > proj4string, then bring it back into ArcGIS, the projection information is > given as the following, and is no longer recognized as identical to the > original. > > Projected Coordinate System: Transverse_Mercator > > Projection: Transverse_Mercator > > false_easting: 520000.00000000 > > false_northing: 4480000.00000000 > > central_meridian: 90.00000000 > > scale_factor: 0.99960000 > > latitude_of_origin: 0.00000000 > > Linear Unit: Meter > > > > Geographic Coordinate System: GCS_GRS 1980(IUGG, 1980) > > Datum: D_unknown > > Prime Meridian: Greenwich > > Angular Unit: Degree > > > > > > > [[alternative HTML version deleted]] > > _______________________________________________ > RsigGeo mailing list > [hidden email] > > https://urldefense.proofpoint.com/v2/url?u=https3A__stat.ethz.ch_mail > man_listinfo_r2Dsig2Dgeo&d=DwICAg&c=n6cguzQvX_tUIrZOS_4Og&r=YFaRLkc > UCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=Ws5QzgjxjD1HGvdDia3XoimuEiDzcY > 4WhCLS905w0&s=gBdaQAI6IxVnnl8qdt_GTEeiM7f2_5dd15qzQOsQ_64&e= > > > > _______________________________________________ > RsigGeo mailing list > [hidden email] > https://stat.ethz.ch/mailman/listinfo/rsiggeo >  Edzer Pebesma Institute for Geoinformatics (ifgi), University of Münster Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081 Journal of Statistical Software: http://www.jstatsoft.org/ Computers & Geosciences: http://elsevier.com/locate/cageo/ _______________________________________________ RsigGeo mailing list [hidden email] https://stat.ethz.ch/mailman/listinfo/rsiggeo 
Administrator

In reply to this post by Shaun Walbridge
Hi Shaun,
Yes, this would be an option, as would be avoiding shapefiles. Could you (or Glenn) check that the same problem exists with a GPKG written by ArcGIS and read into R using rgdal::readOGR() and sf::st_read(), and then written out again using rgdal::writeOGR() and sf::st_write? A recent issue on github at edzer/sfr showed that GPKG can be more effective at handing this kind of issue than ESRI Shapefile formats. OGC GPKG should be advanced strongly as the preferred modern format eradicating Shapefiles as soon as possible (for numerous reasons, including encoding, field name lengths, etc.). I don't have a current ESRI license, or I'd try the GPKG roundtrip myself. I'd much rather spend time fixing things for GPKG (or SQLite) than shapefiles. Best wishes, Roger On Wed, 14 Jun 2017, Shaun Walbridge wrote: > Glen, > > Roundtripping projection information can be tricky, in part because the > normalization routines vary between different stacks, and what counts > as the same form is also implementation dependent. In this case > (roundtripping with ArcGIS), you may be better off using the > arcgisbinding package [1], which can do the conversion to and from > ArcGIS native data types (including some that aren't available via > OGR/GDAL). It's easy enough to install [2], and also lets you build > Geoprocessing tools which speak directly to R. I imagine there's also a > pure R solution to the normalization, but it would likely have side > effects for existing packages, and may not be easily solved. > > If you know that your data is fine and want a simple solution, you could > also just overwrite the new shapefile’s .prj file with a copy of the > original. > > Cheers, > Shaun > > 1. https://urldefense.proofpoint.com/v2/url?u=https3A__r2Darcgis.github.io_assets_arcgisbinding.pdf&d=DwIGaQ&c=n6cguzQvX_tUIrZOS_4Og&r=fCPRb7QXvd5bnO9gIJHCiX852SVUtyYXxtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W0Tm65yvo7NmjLw&s=pIBxR3icnDLcn639TzBc0mkXy6Tv7G9Ip7xcWSAMweU&e= > 2. https://urldefense.proofpoint.com/v2/url?u=https3A__github.com_R2DArcGIS_r2Dbridge2Dinstall&d=DwIGaQ&c=n6cguzQvX_tUIrZOS_4Og&r=fCPRb7QXvd5bnO9gIJHCiX852SVUtyYXxtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W0Tm65yvo7NmjLw&s=JADt055JJUuCG1eltd7N9o5f_fu_geqGlnzO62SGtGM&e= > > On 6/14/17, 9:35 AM, "RsigGeo on behalf of Glenn Stauffer" <[hidden email] on behalf of [hidden email]> wrote: > > I have a shapefile that I imported into R using readOGR from the rgdal > package. I do a little bit of work with it, like adding attribute > information, etc, then export it as an ESRI shapefile again, with a new > name. However, when I bring both the original and new shapefile into ArcGIS, > it tells me that the CRS do not match. > > So, noting that all the projection parameters remain the same, but the > projection and coordinate system names are different, and the datum name is > dropped, my questions are: > > 1. Is the second CRS the same as the first? > 2. If so, why did the names change, and why does ArcGIS no longer > recognize it as the same? > 3. If not, how did it get changed? > 4. Can the proj4string be modified to be more specific, and if so, why > did readOGR not already do this to preserve all the information? > > I can use the new shapefiles just fine and readOGR interprets them as > identical, but it is a bit vexing that ArcGIS does not. And, I could of > course define it again in ArcGIS, but part of the motivation to work in R is > to obviate the need to point and click for many files. > > I appreciate any insights or enlightenment. > > Thanks, > > Glenn > > Here is the original projection information from ArcGIS: > > Projected Coordinate System: NAD_1983_HARN_Transverse_Mercator > > Projection: Transverse_Mercator > > False_Easting: 520000.00000000 > > False_Northing: 4480000.00000000 > > Central_Meridian: 90.00000000 > > Scale_Factor: 0.99960000 > > Latitude_Of_Origin: 0.00000000 > > Linear Unit: Meter > > > > Geographic Coordinate System: GCS_North_American_1983_HARN > > Datum: D_North_American_1983_HARN > > Prime Meridian: Greenwich > > Angular Unit: Degree > > Here is the proj4string from R, which also agrees with the proj4string given > for this projection at www.spatialreference.org for epsg:3071 and also for > SRORG:7396. > > +proj=tmerc +lat_0=0 +lon_0=90 +k=0.9996 +x_0=520000 +y_0=4480000 > +ellps=GRS80 +units=m +no_defs > > When I use writeOGR to export the SpatialPolygonsDataFrame with the above > proj4string, then bring it back into ArcGIS, the projection information is > given as the following, and is no longer recognized as identical to the > original. > > Projected Coordinate System: Transverse_Mercator > > Projection: Transverse_Mercator > > false_easting: 520000.00000000 > > false_northing: 4480000.00000000 > > central_meridian: 90.00000000 > > scale_factor: 0.99960000 > > latitude_of_origin: 0.00000000 > > Linear Unit: Meter > > > > Geographic Coordinate System: GCS_GRS 1980(IUGG, 1980) > > Datum: D_unknown > > Prime Meridian: Greenwich > > Angular Unit: Degree > > > > > > > [[alternative HTML version deleted]] > > _______________________________________________ > RsigGeo mailing list > [hidden email] > https://urldefense.proofpoint.com/v2/url?u=https3A__stat.ethz.ch_mailman_listinfo_r2Dsig2Dgeo&d=DwICAg&c=n6cguzQvX_tUIrZOS_4Og&r=YFaRLkcUCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=Ws5QzgjxjD1HGvdDia3XoimuEiDzcY4WhCLS905w0&s=gBdaQAI6IxVnnl8qdt_GTEeiM7f2_5dd15qzQOsQ_64&e= > > > > _______________________________________________ > RsigGeo mailing list > [hidden email] > https://stat.ethz.ch/mailman/listinfo/rsiggeo Roger Bivand Department of Economics, Norwegian School of Economics, Helleveien 30, N5045 Bergen, Norway. voice: +47 55 95 93 55; email: [hidden email] EditorinChief of The R Journal, https://journal.rproject.org/index.html http://orcid.org/0000000323926140 https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en _______________________________________________ RsigGeo mailing list [hidden email] https://stat.ethz.ch/mailman/listinfo/rsiggeo
Roger Bivand
Department of Economics Norwegian School of Economics Helleveien 30 N5045 Bergen, Norway 
Free forum by Nabble  Edit this page 