Tag Info

New answers tagged

2

Please note that Proj.4 and proj4js are not identical. If you download the latest version of proj4js, you find the defined projections in the lib/projections folder. Regarding EPSG codes, proj4js only has a few definitions, look into lib/global.js or see http://proj4js.org/ But it is possible to build all other definitions yourself if you take the proj4 ...


0

Coord sys tab ArcMap 10.2.2 ArcMap tells me that DHDN Gauss Zone 3 is also Bessel based (the Deutsches Hauptdreiecksnetz datum). So no trandformation is required. If you do want to transform your data to a WGS84 base, then there are a stack of transformations available. Including Ntv2 method.


1

The first step is ensure which data have the proper information, for this matter I would try to get the coordinates from other resources (google maps, OSM, geographic services in your country),if you can identify a geodesic vertex will much better. When you compare with your data you can identify the wrong information. In case of your DGN file have the ...


1

At the end I used the shapefile from the National Land survey of Finland even though not perfect, they seemed to be of a higher quality


0

As suggested by @user30184 the kapsi repository had what I needed, it can be found at this link


1

This interaction does not support custom projections. In the code, the private ol.interaction.DragAndDrop.prototype.handleResult_ calls the code below: var readFeatures = this.tryReadFeatures_(format, result); This code itself return format.readFeatures(text) (where format is ol.format.GeoJSON). If custom projections were supported, it would be ...


1

You would only use a datum transformation if you wanted to transform your data based on Bessel to another model like WGS84/ETRS89. If all your data has a common (Bessel) base to don't need to do this. When the data frame in ArcMap has data with several different datum(s), a warning should pop up. Get to the dataframe properties page, coordinate system tab. ...


0

As long as you stay on the bessel ellipsoid, your data is pretty accurate after reprojecting to Gauss-Krüger. You might run into datum shifts if you add WGS84 (or ETRS89) based data. There is a bunch of valid datum shifts between bessel and WGS84, depending on the part of Germany you work on. Most accurate will be using a NTV2 datum shift grid, but this is ...


1

Figured it out. I needed to add in: map.aspect_fix_mode = mapnik.Map.ASPECT_RESPECT; before: map.extent = bbox;


0

What you are looking for is to calculate points along a path starting at a specific lat/lon and bearing. You will want to pick an distance increment (e.g., 100 miles) to incremently plot points following the bearing across the globe. This stackoverflow answer gives such a formula using the Great Circle method for approximately the spherical of the globe: ...


0

I think the formula you are looking for is the haversine formula. See the Destination point given distance and bearing from start point section. Here's an R implementation to add to those given on the site: # Q: From London, what is 500 kilometres away in the heading of 110 degrees # London coordinates earthR <- 6371 # km olat <- 51.5073509 / 180 * ...


0

As mentioned in the comment, a possible problem is the precision of your dataset, which could eplain that the data do not align. However, 20 m seems to be quite large especially in Kentucky where I would expect bing map to be at least below 5 m. The more likely issue is the absence of transformation between WGS 84 and NAD83 when you use "on the fly" ...


1

Just to clear up: GEOS works only on the Cartesian plane. The best practice to implement geometric operations on either a sphere or ellipsoid of revolution (spheroid) is to project to a Cartesian projection, perform operations in Cartesian space, then transform the results back to a geographic projection. If the data are in a small region, use a UTM zone. ...


6

Possible error of your geometric operation depends on: overall size of the objects - bigger size increase errors, projection that you use, datum that you use (each datum suits some parts of the Earth more than the others) quality of your data. Generally you don't want to work with unprojected data at all unless there is some specific reasons like ...


1

Map projections inevitably introduce distortions either in distance or in area, direction etc. For projections designed for a relatively small geographical area, such as a State Plane coordinate system, certain types of distortion are often negligible/tolerable. An appropriate projection should be chosen carefully for each type of measurement, especially ...


2

This looks ok. If you run into reprojecting problems, try the spherical version, as I explained here: Manipulating Azimuthal Equidistant Projections in QGIS


1

Since the png file has no georeferencing information, you have to georeference the file manually. This is rather simple if you have QGIS, and use Natural Earth shapefiles as reference, or the Openstreetmap background from the Openlayers plugin. Gdalwarp needs GCP ( Ground control points), and you get those with QGIS by just clicking on the image and on the ...


2

The value k = 0.0818191908426 is referred to as the First Eccentricity of the Earth. This value is used in equations to convert between coordinate system values of position, such as lat-long-alt to ECEF coordinates.


2

Traditionally, topographic maps are plotted using a conformal projection, not an equal area projection. A conformal (or orthomorphic) projection preserves angles and, at any point, has isotropic scaling. Such qualities allow relatively easy computations involving angles and distances. en.wikipedia.org/wiki/Map_projection#Conformal ...


2

Here is the source to the underlying Java library, prj2epsg, used behind the scenes on the webpage you list. Basically, it uses a Lucene index to get the best match between the WKT in your prj file and an underlying EPSG. As AndreJ has already said, this may not be 100% perfect, but Lucene excels at partial/fuzzy matching. gdalsrsinfo might be easier to get ...


2

There is no such tool working 100% perfectly, because there are many EPSG codes that share the same projection parameters. You can run gdalsrsinfo on any Geotiff or shapefile .prj file to get the proj string out of the definition. For some intelligent ways of guessing, follow the answers given here: Identifying Coordinate System of Shapefile when Unknown? ...


1

R projects sp objects using proj4 strings. After some googleing, I got the impression that interrupted projections are not easily accomplished via proj4 arguments. Sounds like the mapproj package doesn't support interrupted projections either. I bet there is a solution, but probably not an easy one (e.g. check out this R-sig-Geo answer: ...


0

In a paper The State Plane Co-ordinate System, regarding Lambert’s Conformal Conic Projection: In order to obtain grid co-ordinates on a Lambert projection, we must remember that the grid co-ordinate system is a rectangular system, which is different to the ‘fan-shaped’ appearance of the projected region. So there will be a grid convergence factor ...


2

Here is an example that does roughly what you ask for. The main parameters are the geotransform array that gdal uses to describe a raster location (position, pixel scale, and skew) and the epsg code of the projection. With that, the following code should properly georeference the raster and specify its projection. I did not test this much, but it seemed to ...


3

Try the EPSG Geodetic Parameter Dataset which is more up-to-date and where epsg.io got its information. Admittedly, it doesn't always have projected coordinate reference systems that are suitable for an entire country--but only because no one's told us what is used for a map of the entire country! Spatial Reference allows user-contributions so might have ...


3

Try epsg.io. You can type in the name of a country or even search by CRS. And it is free!


0

Hopefuly it will be implented one day (http://hub.qgis.org/issues/4236). Meanwhile I create JPGs from TIF using gdal_translate and creation option -co WORDFILE=YES. It creates *.wld file plus *.aux.xml containing: <PAMDataset> <SRS>PROJCS["WGS 84 / Pseudo-Mercator",...]</SRS> </PAMDataset> JPGs created this way are opened by ...


0

Try this: PROJCS[ "Popular Visualisation CRS / Mercator", GEOGCS[ "GCS_WGS_1984", DATUM[ "D_WGS_1984", SPHEROID[ "WGS_1984", 6378137.0, 298.257223563 ] ], PRIMEM[ "Greenwich", 0.0 ], UNIT[ ...


0

To check the spatial reference, right-click the feature class/shapefile/raster and select properties, then the source tab. You should see both a projected and geographic coordinate system. If you don't, or its wrong, follow Erica's answer.


2

First open up ArcToolbox. Then there are two possible tools you can use (both in the Data Management / Projections and Transformations toolbox), depending on the specific situation: To define the projection, use the Define Projection tool. Do this when: no projection is currently assigned, or the current projection is incorrect (e.g., data should be in ...


2

You can set the Output Coordinate System (Environment setting), but only certain tools will honor it. I don't think it will help for what you're doing. Why don't you just use coordinate pairs that are in the projected coordinate system you want to use? And then set the spatial reference when you create the polyline? arcpy.Polyline(inputs, ...


1

The reprojection might fail for points that are located at the backside of the globe. Best solution is to clip the data to the visible hemisphere. I have given some advice on that here: Where did the polygons go after projecting a map in QGIS? and in the questions in the Linked section of that topic.


0

There does not seem to be any limitations measuring across the antimeridian with this library: library(geosphere) # small distance across the antimeridian distVincentyEllipsoid(c(-179.999, 0), c(179.999, 0)) # 222.639 # this should be zero, but tiny errors have entered in the maths distVincentyEllipsoid(c(-180, 0), c(180, 0)) # 1.556904e-09 And if you ...


3

Disabling the "on-the-fly" projection setting should yield you the correct results when performing analytics via the Field Calculator: Project > Project properties > CRS This bug has been known in early versions of QGIS but has mostly been resolved since QGIS 2.1.


1

+vunits=m is for vertical datums. Since QGIS is still two-dimensional, it has no impact on the projection. For more details, see http://trac.osgeo.org/proj/wiki/VerticalDatums and http://osgeo-org.1560.x6.nabble.com/Vertical-and-geocentric-coordinate-support-in-OGR-PROJ4-td3841151.html


0

It helps if you cut your EPSG:4326 shapefile at 89.9° North. The points at the 90° North line will all fall into one point (the North pole). That might break the polygon definition after reprojection. In your screenshot, you have swapped input layer and clip layer. Therefore you get only the attributes form the cliplayer (presumably nothing). To check the ...


0

It's actually a bug in GeoServer. GeoServer in it's WFS implementation specifies the order of coordinates for different versions and projection definitions (link) but GeoJSON states specifically that the order is always the same (x,y,z or lon,lat,alt). See the spec.



Top 50 recent answers are included