New answers tagged

0

I have solved it - the map 'screwing up' was, of course, the land masses going beyond +/- 180 degrees. The solution is therefore to clip the land mass data against the gore shape before rendering, which prevents this from happening (and is a little neater than the mask anyway). I never found out why the projection wasn't updating after I had edited the WKT, ...


0

Proj.4 knows the Icosahedral Snyder Equal Area projection +proj=isea, but not the inverse projection. For that reason, it is not usable by GDAL. I guess the Waterman Butterfly projection will fail for the same reason. Waterman butterfly projection in Mapnik lists some alternatives.


0

You can define a south-up CRS with +axis=wsu. That indicates X is west, Y is south, Z is up. It doesn't save that in the prj file though. When you load a layer with this projection, you have to set the CRS in the layer properties. Other than that it works properly.


1

If you set the project CRS to a south-up projection like EPSG:22281 Cape / Lo21, you will get a map with the South pole upwards: Note that common raster basemaps like Openstreetmap will have labels upside down as well with this projection, whereas labels of your vector data will appear in a readable orientation.


5

You can rotate your map (without projection requirements) : In the canvas, use the field "Rotation" at the bottom of the main window : In composer, use the "Map rotation" field of the main properties of your map :


2

Gall-Peters can be used in QGIS with a custom CRS. See my example at Getting Borders as SVG using Peters Projection? For Hobo-Dyer, see the projection string given in Proj4 string for Hobo–Dyer projection? Behrmann is also possible, see What is the proj4 for World Behrmann (54017)?


1

The integrized grid is sparse, in a sense it is a ragged array. Looks like the sinusoidal one really is a full array, albeit with empty tiles. The integrized sinusoidal grid is still used by the ocean colour group for L3BIN MODIS (and VIIRS, SeaWiFS, CZCS etc), recently converted from HDF4 to NetCDF4 (as compound types within groups) fwiw. The bins are ...


0

I solved by using conversion functions from proj4js.js


1

For proj.4 those two mean exactly the same and conversion from one system to another changes only the EPSG code. If you work with geodetic problems which require accurate ellipsoid model you will need some other tools. # ETRS89 <4258> +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs <> # WGS 84 <4326> +proj=longlat +datum=WGS84 ...


1

DO NOT use Set Layer CRS unless you are told to do so. It will corrupt your data. Instead, use Save As ... to a new filemane and different CRS for vector data, and Raster -> Projections -> Warp for rasters.


0

Seems like you calculated the area after you erroneously defined the layer's crs to be a projected UTM crs from a geographic one. This is wrong. Export your polygon layer to a new layer with the required CRS, then change the map canvas CRS to the same one. This way your calculation will be correct Example: Here is your polygon when defined in WGS 84 ...


0

Socalgis.org is your best bet to find it.. https://socalgis.org/?s=NAIP&submit=Search


2

I long ago implemented Cahill-Keyes in D3.js following Gene Keyes' great documentation/code on his website. You can find it in this bl.ock Here is a snapshot:


2

From my reading of the documentation it looks like you have the source and target of your transform reversed, so you are transforming from 900913 to 4326 rather than from 4316 to 3957 which is what you need. So change center: ol.proj.transform([51.714090, -0.413285], 'EPSG:900913', 'EPSG:4326'), to center: ol.proj.transform([51.714090, -0.413285], '...


1

It looks like you have the XY and source.destination CRS flipped in your transform. Also, code 900913 is deprecated, use 3857 instead. center: ol.proj.transform([-0.413285, 51.714090], 'EPSG:4326', 'EPSG:3857'),


0

You probably have used Set Layer CRS to switch from a degree CRS to Albers equal. This is the wrong tool, and it has corrupted your data. So you better set it back to WGS84 or NAD83. Instead, use Raster -> Projections -> Warp to a different filename and target CRS, and remove the original layer from your canvas.


0

Before you run GRASS, make sure that the project CRS is set to the CRS of the layer you are working on. Then output and input layer CRS should be the same. Save As is not useful for reprojecting rasters (it only works for vector data). Instead, use Raster -> Projections -> Warp to a different filename and CRS, or Set Layer CRS ONLY if the raster is ...


0

If you want to change the CRS of the raster, use Raster -> Projections -> Warp(Reproject), choosing a different filename and WGS84 EPSG:4326 as target SRS. DO NOT use Set Layer CRS for this task, it will corrupt your data. To avoid future mistakes, remove the original layer from the canvas, and set the project CRS to WGS84 as well. With the raster ...


1

Updating R and sp to the released versions will resolve this. It was caused by a change in R's behavior on what nchar(NA) returns: see the help file of ?nchar, argument keepNA.


0

In applications that display EPSG:3857 basemap tiles, latlngs supplied to L.markers are reprojected, but not transformed. Another way of saying this is that Leaflet assumes that lat/long coordinates share the same WGS84 (EPSG:4326) datum as the basemap tiles. The good news is that Esri's hosted tile services (which use the tiling scheme popularized by ...


2

Projection of this kind of files is sinusoidal. For this one: ftp://ladsweb.nascom.nasa.gov/allData/6/MOD13Q1/2016/129/MOD13Q1.A2016129.h07v06.006.2016147112419.hdf the next code can access to coordinates for 256 values for subDatasets[0][0] (NDVI values). from osgeo import gdal import struct nameraster = "/home/zeito/Desktop/MOD13Q1.A2016129.h07v06....


3

You should not have to do any particular conversion on your OSM data or Leaflet returned coordinates. There is a high confusion on this subject, but I think it comes down to a simple explanation: OSM data is in WGS84 datum (EPSG 4326). This is how you plot the Earth onto an ellipsoid. Web Mercator (EPSG 3857) is how you project this ellipsoid onto a plane....


1

That's tricky, assuming they were "Okay" on ENVI, All you have to do now is reproject your output in your wanted projection. Don't use anything special though : Access them via ArcCatalog. Right click on your Output and define your spatial reference (overwrite ENVI's)


4

There is nothing wrong with your data. It is just the fact that OS still issues coordinates in OSGB36, while Google uses WGS84: So you have to assign EPSG:4277 to your degree coordinates, or EPSG:27700 for raster data in projected coordinates. Make sure that both projections have a `+towgs84' datum shift.


2

Since the data that you have in WGS 84, this means that the cell size is in degree unit. In order to get the cell size in meter, you need to change the projection of your raster from WGS84 to meter projection such as UTM or any other projections that is meter unit depending of the size of the study area. To change the projection of your raster data in ArcGIS ...


2

As far as the projections are concerned, this answer explains it really well. Once you have the coordinates in either EPSG:4326 or EPSG:3857 you should be able to covert them fairly easily, using either PostgreSQL or online convertors like this one. Getting the actual coordinates of a place or point in GoogleMaps is as simple as just clicking on the map. ...


0

The problem here is that you have THREE coordinate systems.... The lat-long coordinates you get from a GPS, also known as WGS 84 or EPSG:4326 The transformed coordinates of the projection. Often these are in metres or kilometres on the ground in an approximate cartesian (ie right-rectangular) coordinates. What are the units of these? Is the detailed ...


2

For such a small area as that the projection probably won't matter, the earth is essentially flat at that scale. Just define a few reference points in whatever output coordinate system you want to use (Some UTM Zone, maybe) and that should be fine. I doubt any precision error will be down to not specifying a projection, it'll probably be swamped by the ...



Top 50 recent answers are included