Tag Info

New answers tagged

3

You can't transform from one SRID to another without knowing what the SRID you are transforming from is. It looks like in your case that the coordinates are Spherical Mercator, which is SRID 3857. So, if this is true, then you can use ST_Transform in conjunction with ST_SetSRID: UPDATE roads SET geom = ST_Transform(ST_SetSRID(geom, 3857), 4326); and then ...


0

Thats because effectively you say "the coordinate 698745.50201423 4210011.04002000 is in SRID 4326", which is not what you want. You want to transform the coordinate from your source reference system to a destination reference system. So you need to: Know the source coordinate system Use ST_Transform ( see http://postgis.org/docs/ST_Transform.html )


0

If you have data from the poles, avoid EPSG:3857, because that is undefined at the poles. Reprojection might fail, and the rest of the data might get lost. Try EPSG:4326 instead. To get the full picture, include the target extent (for the Arctic region): gdalwarp -t_srs EPSG:4326 -te -180 -90 180 90 northpsg.20141027 output.tif and you will get your ice ...


2

Two separate marker-transform properties can't be applied for the same object, but if you can apply a single property with multiple functions in it: marker-transform: 'scale(0.5) rotate(180)'; However this would likely require you rearrange your code to apply the correct rotations at the same time and make things more complicated. A simpler approach ...


0

You may have swapped the coordinates somewhere. If I reproject your resulting lonlat coordinates 103.919768 1.125312 103.690059679 1.35650722603 I get with cs2cs using: cs2cs -f "%%.6f" +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs +to +proj=tmerc +lat_0=1.366666666666667 +lon_0=103.8333333333333 +k=1 +x_0=28001.642 +y_0=38744.572 +ellps=WGS84 ...


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

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


2

Since your data is already in UTM 34N projection, all you have to do is reproject it to your local CRS. You can do this with gdalwarp (even in batch mode for a whole folder), or inside QGIS with Raster -> Projections -> Warp . ARCGIS should offer similar tools. So no need for georeferencing manually.


2

Inspired by WhiteboxDev's comment I have added MODIS support to i.tasscap in revision 62197. It is yet untested, please try it and report if all works fine. In order to obtain this improvement, you need to either install/update GRASS GIS 7.1 or even simply grab the updated i.tasscap (which is a Python script here).


1

The GRASS program that you linked to was written by Markus Neteler and he's done an excellent job of documenting the code. It appears that the tool has been written with the Tasseled Cap transformation (TCT) coefficients that are specific to Landsat TM and ETM (Landsat 4, 5 and 7). He makes a note in the documentation about whether or not it would make sense ...



Top 50 recent answers are included