Tag Info

Hot answers tagged

6

With 10.2 and above, you can use the Add Geometry Attributes tool to add a field with the length of the features. The tool lets you specify the coordinate system you want to use, in case it is different from the dataset's system. With 10.0, you should work in ArcMap: set the coordinate system of the data frame to WGS 1984 UTM 32N add a field to your ...


5

The Albers equal area conic is the typical projection for historical USGS maps of the lower 48, it being a general-purpose low-distortion compromise for mid-latitude short and wide extents. As a reference on map projections, I like the ESRI book Understanding Map Projections. Its first 30 pages are not unlike a short textbook, followed by ~70 pages of ...


3

This is not really a raster in longitude latitude, it's just arrays of values (including longitude and latitude). You can deal with these explicitly like this: f <- "F18-SSUSI_EDR-NIGHT-DISK_DD.20150107_SN.26920-00_DF.NC" library(raster) ## treat these not as rasters, but as arrays of values ## though raster() is extremely helpful in simplifying the ...


2

ESRI has defined three projections especially for the contiguos United states. These are included in QGIS as well: EPSG:102003 USA_Contiguous_Albers_Equal_Area_Conic +proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=37.5 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD83 +units=m +no_defs EPSG:102004 USA_Contiguous_Lambert_Conformal_Conic +proj=lcc +lat_1=33 +lat_2=45 +lat_0=39 ...


2

You have to transform the vector layer with a right click on it > "Save as..." You will save a new vector layer (for example "points_21781.shp"). Change the CRS in your 21781, CH1903 / LV03. The new vector layer will have the right CRS.


1

If both layers are UTM and do not align, there is a chance that they don't share the same datum. So one can be ED50 UTM 32N, and the other WGS84 UTM 32N. In this case, Rightclick -> Set CRS for Layer is the right tool to change one layer or the other (but not both, because then they will both end up shifted, but not relative to each other).


1

This code snippet is C# and using an array called vertex to hold [x, y] double smRadius = 6378136.98; double smRange = smRadius * Math.PI * 2.0; double smLonToX = smRange / 360.0; double smRadiansOverDegrees = Math.PI / 180.0; ... // compute x-map-unit vertex[0] *= smLonToX; double y = vertex[1]; // compute y-map-unit if (y > 86.0) { vertex[1] = ...


1

Try projecting your data to 4326 (WGS84) instead of 3857. Leaflet expects coordinates in geojson to be 4326. It'll probably easier to reproject your data before including it your app rather than adding Proj4Leaflet to do on the fly reprojection. Plus, if you don't use Proj4Leaflet, that's one less dependency in what you're developing.


1

I'm not sure what the cause of the problem is, but if you're using ArcGIS you can use the "Move" edit tool (help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//…) to move it back to where it should be.


1

@mr.adam covers a lot. One more suggestion; while coordinate systems are no longer in folders, they don't need to be actual files now. See: Geographic coordinate systems Projected coordinate systems You can then create your spatial reference object as such: For NAD 83 UTM Zone 10: By name: SRbyName = arcpy.SpatialReference ("NAD 1983 UTM Zone 10N") ...


1

Well, your questions seem to mostly be about user input. I would recommend using a dropdown menu in the tool dialog with coded values, and then a dictionary in the script itself that links each coded value with the full text string that you need. For example, in your dropdown for "Convert to Coord System" list "NAD 1983" and "WGS 1984". Set this in the ...


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


1

Unfortunately, the data has no projection, because it is satellite raw data captured during the flight around the earth. The first two subdatasets contain the lonlat values, but these are not understood by GDAL. So I tried to make a scatterplot out of the data: I extracted the first three datasets to XYZ format: gdal_translate -of XYZ ...


1

The projection you are setting (proj4string(pr) <- "+proj=longlat +datum=WGS84") is wrong. That should be the projection of the original data, not the target projection. You say that the data is NOT on a lat-lon grid, so you have to find out which CRS your data has. Looking at the .nc file, it's not contained there, so you have to look through the docs ...


1

I discovered my error. I was expecting to see lat/lng pairs from EPSG:3857, but it's actually EPSG:4326 I should have been converting to.


1

I know this is an old question but I was stuck too (I have to model a 3d globe that uses a TMS) and found the "altitude" of the camera partly thanks to Igor Brejc's reply and mostly thanks to this article: http://wiki.openstreetmap.org/wiki/Zoom_levels there is a mistake in their formula btw ; the +8 in S=C*cos(y)/2^(z+8) should not be there. in my case ...



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