I've been trying to find out what the projected bounds are for EPSG:3575 but have not been able to find a definitive answer. Normally, I'd just use the values from EPSG.io but when I tried these in mapserver and geowebcache they both threw back error messages saying 'min x, miny, max x, max y not valid'. I've also tried the values from spatialreference.org and whilst these are valid, the cache gridset I created in GWC then did not work with several WMS services from other organisations. I have also found this site http://nsidc.org/data/atlas/epsg_3575.html, but this just gives the same info as the EPSG registry in effect. Ive tried converting the 4326 bbox to 3575 in a couple of programs (ogr and a web conversion site), but these just out with differing answers, neither of which look correct. any help would be gratfully received!
From http://spatialreference.org/ref/epsg/3575/
WGS84 Bounds: -180.0000, 45.0000, 180.0000, 90.0000
Projected Bounds: 0.0000, 0.0000, 849024.0785, 4815054.8210
Related
I am currently working on a sf dataset of points in R, and I want to transform that dataset to an SpatialPointsDataFrame for some downstream analysis. This seems easy enough so I use the as_Spatial() function, but it throws an error that I've never seen before:
Error in sp::CRS(SRS_string = from$wkt) : unused argument (SRS_string = from$wkt)
The object I'm trying to transform is a little large for me to add to the question, but the basic object information is as follows:
Simple feature collection with 1357 features and 10 fields
geometry type: POINT
dimension: XY
bbox: xmin: 2.763816 ymin: 4.292756 xmax: 13.66089 ymax: 13.76644
geographic CRS: WGS 84
I tried to transform the CRS code of the object, thinking it might have a string that the as_Spatial function isn't recognizing. But when I tried to use the st_transform() function, it doesn't look like it updated the geographic CRS. I guess one workaround is change my workflow upstream so that I don't use sf objects, but that would mean throwing away a lot of prior work and use the less efficient intersect() function instead of the st_join() function. If anyone has any idea where I can look to troubleshoot this issue, that would be fantastic. Thank you all.
I did a little more digging and it looked like the CRS for the sf object was incorrectly set. For some reason when I loaded in the initial shapefile prior to my spatial join, the CRS incorporated a ton of extra information that sf ended up not able to handle. I used st_crs() to reset the CRS information and that resolved the issue.
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 does 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 questionas are:
Is the second CRS the same as the first?
If so, why did the names change, and why does ArcGIS no longer recognize it as the same?
If not, how did it get changed?
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, but it would be nice to know that
the CRS is identical to the original. 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.
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 SR-ORG: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 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
Perhaps not a definitive answer, but I posted this question on the R-sig-Geo list serve, and got a few possible work-around solutions. For now, I simply used an R-script to overwrite the .prj file with a copy of the original, and that seems to work fine. Also suggested was the use of a package called arcgisbinding to bridge ArcGIS and R (and maybe a similar solution would be available for QGIS?). I have not verified the arcgisbinding solution, but more information can be found at the the blog post here and in the package documentation here.
I've question about units in fields Db_GpsPt_dX,Db_GpsPt_dY from table Table_GpsPtArray_Point_Array located in every *.db (sqllite format) file maintained by Landstar application for GPS-RTK measurement. Unfortunatelly (CHC) Producer's support didn't response for my request, so i hope StackOverflow will be more helpful.
I know that for base points units are in ECEF units (WGS cartesian) but for rest of measured points there are values, that aren't corrected delta values either in ECEF, local XY oraz WGS84 (decimal). It is weird, units in given column should be written in the same format, but it isn't for that file.
Anyone has ideas about meaning of mentioned fields? Thanks for help.
OK problem solved - i've just realized that 0,898 0,344 coefficients are an absolute coordinates in WGS84 datum written in radians.
I try to find a way to get the projection type of the following coords.
I need to convert these coords in WGS84 latitude longitude format. I have only 1 hint: these coords are located in Florida-USA (Broward County)
<XCoordinate>9082520</XCoordinate>
<YCoordinate>6563620</YCoordinate>
Thanks
I suspect your data are in "SPC" (State Plane Coordinate) system. This is often used for "local" coordinates - it makes calculations for such things as distances and routes much easier. If that is the case, and the county in question is Broward (which is zone 0901), then there is still some guessing to do... because one can use "US feet", "International feet", or meters in this system.
If you go to http://www.earthpoint.us/Convert.aspx you can enter your coordinates in the "Position" box. Depending on what you choose you will get different answers. I suggest you try to see which makes sense (if you suspect the coordinates are for a post office and you land in a lake you probably are using the wrong number):
0901 908252.0ftE 656362.0ftN gives 26°08'14.5036", -080°13'53.8483"
That puts you pretty much on top of a bus stop - which I guess is what the Hastus system might be giving you...
I am in charge of a program that is used to create a set of nodes and paths for consumption by an autonomous ground vehicle. The program keeps track of the locations of all items in its map by indicating the item's position as being x meters north and y meters east of an origin point of 0,0. In the real world, the vehicle knows the location of the origin's lat and long, as it is determined by a dgps system and is accurate down to a couple centimeters. My program is ignorant of any lat long coordinates.
It is one of my goals to modify the program to keep track of lat long coords of items in addition to an origin point and items' x,y position in relation to that origin. At first blush, it seems that I am going to modify the program to allow the lat long coords of the origin to be passed in, and after that I desire that the program will automatically calculate the lat long of every item currently in a map. From what I've researched so far, I believe that I will need to figure out the math behind converting to lat long coords from a UTM like projection where I specify the origin points and meridians etc as opposed to whatever is defined already for UTM.
I've come to ask of you GIS programmers, am I on the right track? It seems to me like there is so much to wrap ones head around, and I'm not sure if the answer isn't something as simple as, "oh yea theres a conversion from meters to lat long, here"
Currently, due to the nature of DGPS, the system really doesn't need to care about locations more than oh, what... 40 km? radius away from the origin. Given this, and the fact that I need to make sure that the error on my coordinates is not greater than .5 meters, do I need anything more complex than a simple lat/long to meters conversion constant?
I'm knee deep in materials here. I could use some pointers about what concepts to research.
Thanks much!
Given a start point in lat/long and a distance and bearing, finding the end point is a geodesic calculation. There's a great summary of geodesic calculations and errors on the proj.4 website. They come to the conclusion that using a spherical model can get results for distance between points with at most 0.51% error. That, combined with a formula to translate between WGS-84 and ECEF (see the "LLA to ECEF" and "ECEF to LLA" sections, seems like it gets you what you need.
If you want to really get the errors nailed down by inverse projecting your flat map to WGS-84, proj.4 is a projection software package. It has source code, and comes with three command line utilities - proj, which converts to/from cartographic projection and cartesian data; cs2cs, which converts between different cartographic projections; and geod, which calculates geodesic relationships.
The USGS publishes a very comprehensive treatment of map projections.
I'd do a full-up calculation if you can. That way you'll always be as accurate as you can be.
If you happen to be using C++ the GDAL is a very good library.
For a range of 40km, you may find that approximating the world to a 2D flat surface may work, although a UTM transform would be the ideal way to go - in any case, I'd advocate using the actual WGS84 co-ordinates & ellipsoid for calculations such as great circle distance, or calculating bearings.
If you get bored, you could go down a similar line to something I've been working on, that can be used as a base class for differing datums such as OSGB36 or WGS84...