Tag Info

New answers tagged

4

Gi* doesn't care about distance, it cares about weights (which you could set to inverse distance if you want...) so you need to think about how to form weights between raster cells on the whole globe. This is tricky, because at the poles, your cells are a different shape and area to those on the equator, and have a different adjacency relationship with ...


2

I'm currently struggling with similar issues, so feel free to wait for a more authoritative answer. However, I can't recommend an equidistant projection. It sounds great, but keep in mind that the distances are true only along specific lines. Measured along other directions, the distances will not be true. I doubt that you want to use a single projected ...


1

This is apparently not possible with ArcGIS for Desktop, see Esri's article FAQ: Are vertical datum transformations supported in ArcGIS? If you go to the ArcGIS idea page referenced in the article's comments, there is a mention of this being possible in Pro and Runtime, programmatically. To be verified with Esri, I couldn't find any confirmation of this.


2

If you convert from one CRS to another, you will change the cell borders automatically. gdalwarp tries to keep the cell value, but it will also try to interpolate if the new cell size will cover different unreprojected cells. Reducing the cell size with -tr or -ts might solve your problem (but increase the raster file size too).


0

I used qgis to produce a Mercator map. Saved the image. Then use flexify plugin from flaming pear with coral Painstshop(works in Photoshop too) to convert from Mercator to gores. Flexify has lots of conversion options.


3

In QGIS, the projection string for EPSG:3399 is: +proj=tmerc +lat_0=0 +lon_0=15 +k=1 +x_0=5500000 +y_0=0 +ellps=bessel +units=m +no_defs This projection string has no datum shift +towgs84, which I would expect for every transformation from the German DHDN/bessel to the WGS ellipsoid. See this page in German for more information on official transformation ...


1

The problem is not with the projection, probably, but with the clipper. When you clip a raster pixel size changes, by default. For example, clipping ASTER GDEM are ESPG:2039 changes the cell size from 30, -30 to 30.0735,-30.0976. In order to overcome such an issue, you should use the "clip raster by extent" or "clip raster by mask" geo-algorithm from the ...


1

You use a UTM zone when your area of interest fits completely within it or very nearly so. A UTM zone is not appropriate when your area of interest spans several zones such as in your case. A little overlap into a neighboring zone might be ok, but the further away from the zone you pick, the more distortion there will be and the more it matters. I found this ...


0

I’m still not quite sure what went wrong when I hit the “Display XY Data” button, but here’s the work-around that fixed it; I made a new map and put the dataframe into WGS 1984. I then added the excel file and selected Display XY Data. Once that came up I exported that into a shapefile. I then opened a new map, set the dataframe to NAD 1983 (the projected ...


3

Don't choose UTM, end of story. Many large countries choose a single sensible projection for some tasks. Victoria, a small state in my country was extremely foresighted in the late 90's and chose a Lambert Conformal Conic projection suitable for state-wide usage when they were undergoing a datum shift (ADG84/66 to GDA94), rather than hobble along with ...


2

I would suggest the best approach is to find out the primary projection that the national mapping or geomatics agency of the area in question usually uses and use that. I live in canada, covering a lot of UTM Zones, and when not geographic (lat/Long) the provinces generally each use a projection that is appropriate for the size and shape of their region. BC ...


0

Using the proj=tpers projection, define a tilted perspective view using: h: height (in meters) above the surface azi: bearing (in degrees) from due north tilt: angle (in degrees) away from nadir lat_0: latitude (in degrees) of the view position lon_0: longitude (in degrees) of the view position Putting it all together, here is an example PROJ.4 string ...


5

QGIS has a good (in my opinion) mechanism for deciding what to do with input layers that have no coordinate system specification. You can choose one of three ways for QGIS to behave: Always prompt for the correct CRS Always assume that the current project CRS is correct for the input layer Always use a certain default CRS that you choose You can set ...


0

I don't understand where you get your basemap (raster) from, and why it presents those coordinates. It indeed looks like a pixels of the map and not "real" coordinates. However you might need to enable on-the-fly CRS, in order to change the coordinates displayed at the bottom. If your basemap is georeferenced to WGS84, it should not be distorted or shifted ...


1

The ST_Transform function has quite simple parameters: a geometry object and a target SRID. This should do it. SELECT name, ST_AsText(ST_Transform(point,2811)) FROM points;


3

You have to reproject every line into an azimutal equidistant projection based on one of its points, then densify the line. Since all points of your grid are connected to three lines, you can densify those three with the same projection. The Densify Geometry tool allows to densify only selected elements. See my example here on how to create great circles ...


1

correcting the CRS might be the clue: Set CRS for layer is NOT the right tool. Use Save As ... under a different name and CRS to keep the data in the right place.


1

The tool uses by default the EPSG:4326 - WGS 84 CRS. If you project is in EPSG:31467, you can see that the icon of CRS status (right down corner) is now black indicating 'enable on the fly CRS tansformation'. Save your virtual layer temp.shp with the correct EPSG and another name. I tested this in my system. The temp.shp line (EPSG 4326) produced with the ...



Top 50 recent answers are included