Hot answers tagged

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 :


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.


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....


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. ...


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 ...


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], '...


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)?


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....


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.


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 ...


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.


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'),


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.


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)



Only top voted, non community-wiki answers of a minimum length are eligible