New answers tagged

4

Esri has its own projection engine. Most projections and geographic/datum transformations methods are well-behaved when used in an appropriate area of interest. If you get too far outside of a UTM zone, transverse Mercator doesn't always 'inverse' (convert to latitude-longitude) exactly. Projections used for the whole world may have some issues at or ...


1

Yes, it is a meaningful difference, there will be some difference in reprojecting. Those 7 parameters define a datum shift (translation + rotation + scaling). If the postgis reprojection is better than the other one, just add those parameters to the Proj4js definition. You can find additional information on the towgs84 param here ...


9

I don't know which projection engine ArcGis uses, but a very interesting question also for proj.4. So I give it a try to test the proj.4 projection engine within the GNU-R environment. I use the NAD 83 - UTM 17 corners and EPSG 26917 and reproject it 10000 and 1000000 times recursivly and calculate the difference to the start values. Here are the results: ...


3

I think this is a case where you need to test your proposed workflow against some test point features, which are easy to add XY coordinate fields to. Compare the XY values of your initial points with those that you have projected/transformed (however many times), and you will have quantified the difference.


2

As @mkennedy says the LayerFile is a "pointer" to the actual data but it can hold stuff like symbology, definition queries and basic metadata. You can set up the IMapGeographicTransformations or how about doing away with the whole problem by projecting your data into OSGB, create a LayerFile for your data (now in OSGB) and load that? I suggest this ...


1

Tx for the feedback, this is important for others who find this question in the future. Are you using WGS84 in your tilestache configuration? There is also a 'projected' attribute you might have to set. You are using VecTile class, I haven't played with that one yet, but you might be able to get it work (or atleast it will give you some clue/ideas to ...


2

I got the tiles to overlay correctly. The problem was in the re-projection done by both ArcMap and QGIS. When I was checking the reprojected shapefiles in ArcMap and QGIS, they were overlaying correctly and had the correct SRIDs. So I imported the shapefiles in WGS84 in PostgreSQL using the SRID4326 with shp2pgsql then used ST_Transfrom to reproject the ...


0

Would go for GDALwarp as well. Be sure to be consistent with "postings" and "cell" interpretations of rasters. http://www.remotesensing.org/geotiff/spec/geotiff2.5.html


2

I'm still a little unclear on what you are trying to do but if all you need is to simply reproject the native bounds to WGS84 (as GeoServer does) then the following code will work for you: String wkt = "PROJCS[\"unnamed\"," + " GEOGCS[\"WGS 84\"," + " DATUM[\"WGS_1984\"," + " SPHEROID[\"WGS ...


1

Solved: I must use the source CRS from the GDALINFO output, since it is a custom reference. And the Target CRS is the EPSG4326. And then: DirectPosition dpLc = env.getLowerCorner(); DirectPosition dpUc = env.getUpperCorner(); DirectPosition destLc = new DirectPosition2D(); DirectPosition destUc = new DirectPosition2D(); MathTransform transform = ...


1

The process that you need to do in order to reproject your image is called georeferencing. For basic/linear georeferencing, the minimum number of points you need is 3 so if you have 4 corners you should be fine. There's a few tutorials available on the net based on Arc and QGIS tools that can show you how to perform this on raster images. I've never used ...


2

Is the raster format an Esri GRID? If so, the original LCC definition may have used NAD83 (CSRS) which isn't supported in the PRJ.ADF file format used by Esri grids. The definition doesn't match any of the existing Canadian LCC definitions, but it's close. Do try to change the geographic coordinate reference system only to NAD 1983 (North American 1983) ...


3

It looks to me like the Lambert projection file has an error. GRS_1980 is a spheroid, not a datum. The NAD83 datum is based on the GRS_1980 spheroid. I think it is possible that your Lambert projection is actually using the NAD83 datum. Your datum transformation throws an error because you are not trying to transform between WGS_1984 and NAD83. If it were ...


1

This is how you change it to UTM, First you have yo change it to wgs, and then call the function to do the rest function showCoordinates(evt) { var wgs = webMercatorUtils.webMercatorToGeographic(evt.mapPoint); var mp = evt.mapPoint; // Converting The WGS to UTM ...


0

I would reproject the files with gdalwarp. I've done the same for files in EPSG:3763 that I want to convert to EPSG:3857. I compared the results using QGIS and Geoserver and the generated images were fine. Since a small rotation is applied to the images, you might get some black lines on the border (but these lines can be made transparent afterwards). ...


2

There is a straightforward, disciplined way to analyze such data: linear regression. It can work because (a) the range of these points is a relatively small part of the world and (b) to a close approximation over such ranges, projection formulas are nearly linear as a function of latitude and longitude and--with more data--even their departures from ...


2

Yes, it's possible. Convert the known coordinates from lat-long into various coordinate systems and see what matches. Looking at a few of your lat-long values, it seems that your data is in California, so my guess would be California State Plane; this may be in meters or feet, but the conversion will tell you quickly.


2

The distortion in MODIS imagery people mostly worry about is the well known Bowtie effect due to whiskbroom scanning. The Sinusoidal projection, or Sanson-Flamsteed, is an equal area projection and thusly both tiles you mentioned cover roughly the same area and have identical pixel sizes.


2

I downloaded your data and had a play around in QGIS - if I choose EPSG:102022 (Africa_Albers_EAC) it looks like it lines up. Depending on your plans for this that might be close enough - obviously for real science(tm) you'll need to go back to NOAA (or the publications listed) and check. Or you could try editing the spheroid definition below. ...


2

As suggested by @bugmenot123, you have to save your layer as a new layer in order to take into account the new CRS you need. Here are the steps to follow: Right-click on layer name in the Layers group (see screenshot below) Select UTM32 as a CRS Give your layer a new name > click OK Add the new layer in QGIS and check your points position


1

I don't know which is your especific product but, you can fix it by using the OSGeo Shell, of QGIS suite, with the gdal_translate command. I downloaded this *.nc file from your link: air.sig995.1948.nc to try out my approach. It looks in QGIS as in the below image: The Spatial Coverage is: 2.5 degree latitude x 2.5 degree longitude global grid (144x73) ...


0

As mentioned by @AndreJ specifying the EPSG code makes it work. Specifically the following work: ogr2ogr -t_srs EPSG:4326 -s_srs EPSG:7421 ilot_2008_027_wgs84_2.shp ilot_2008_027.shp Alternatively, I was trying to use the qgis python API to do it all in python using qgis but could not get it to work.


4

NTF Lambert II has a towgs84 datum shift, but that is not included in the .prj file. The .prj file uses a different naming for the projection, so the EPSG code finder might fail. I assume QGIS assigns the correct EPSG code (maybe in the .qpj file), and makes a standard transformation from one EPSG code to another using full towgs84 parameters. You should ...


0

If you can't configure tile server (no access for example) you can transform tiles by Mapproxy http://mapproxy.org/docs/1.8.0/configuration_examples.html#reprojecting-tiles



Top 50 recent answers are included