I'm trying to project some point data in ArcMap.
I created the point data in excel, then summarised it in R and exported it as a csv. Then added it through 'add XY data' tool in ArcMap, and exported it from an events file to a shapefile.
The points appear in the correct place, relative to each other, but when tried to overlay on the world imagery basemap, it simply sits down near Antarctica.
I've checked and re-checked the projections of the imported layer and the dataframe (I'd like to work in GDA_1994_MGA_Zone_56), but have also tried changing to a geographic coordinate system, which doesn't change anything.
In fact, when I try to change the projection to a gcs, using the 'project - data management' tool, this error comes up.
invalid extent for output coordinate system
Failed to execute (Project).
I can't for the life of me figure out what is going wrong, there's probably a simple explanation, but I'm at my wits end!
It helps to have them stored originally as numeric data, but since it's actually coming in as a CSV, I think they are importing as numeric -- as you note, they are correct relative to each other.
If your points are showing up on a map but in the wrong location, then their initial projection definition is incorrect. Looking at the Add XY Data dialog, you need to specify an initial coordinate system. If nothing is specified, ArcMap assumes that it is latitude/longitude decimal degrees.
Once it's imported as the wrong coordinate system, attempts to reproject will just continue the But you do not necessarily need to delete the points and start to re-import from scratch. Try using the Define Projection tool (which modifies the metadata to the desired projection) instead of Project (which mathematically recalculates coordinates from current projection to a new projection).
Related
I have two .shp files whose .prj files are identical and whose extents are different. I'd like to set them to the same extent so they line up on the map.
In ArcGis I have tried:
Exporting both to a new coordinate system-defined feature dataset
Removing the .prj file and then re defining the projection of each file
"project"ing both to the same Coordinate system.
Setting the data frame Coordinate System, then reintroducing the shapefiles in hopes that they'll project "on the fly"
In QGIS I have tried:
Setting project CRS
Setting layer to project and project to layer
Saving the shapefiles in specific CRS.
It seems odd to me that this is an issue in the first place: why can't Arc or Q detect this asynchronicity and give the user the option to choose one over the other?
What am I missing here?
Should I look into creating a spatial reference for one of the files, that matches the other?
Any clues/ suggestions/ clarifications?
I know this is a popular issue, and I figure there must be some simple explanation for the above, but I'm not finding it anywhere despite spending hours puzzling over the situation. Perhaps I just don't have the right vocabulary to ask the question. Any help appreciated.
some information about the files:
Extents for shp1:
top: 672344.187336 ft
bottom: 629117.938976 ft
right:7660465.885171 ft
left: 7627858.786745 ft
Extents for shp2:
top: 5984.800593 ft
bottom: 4784.800593 ft
right: 4616.411043 ft
left: 3776.411043 ft
Layer Properties-Source for both shp1 and shp2:
Projected Coordinate System: NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601_Feet_Intl
Projection: Lambert_Conformal_Conic
False_Easting: 8202099.73753281
False_Northing: 0.00000000
Central_Meridian: -120.50000000
Standard_Parallel_1: 44.33333333
Standard_Parallel_2: 46.00000000
Latitude_Of_Origin: 43.66666667
Linear Unit: Foot
Geographic Coordinate System: GCS_North_American_1983_HARN
Datum: D_North_American_1983_HARN
Prime Meridian: Greenwich
Angular Unit: Degree
.prj data for both shp1 and shp2:
PROJCS["NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601_Feet_Intl",GEOGCS["GCS_North_American_1983_HARN",DATUM["D_North_American_1983_HARN",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",8202099.737532808],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-120.5],PARAMETER["Standard_Parallel_1",44.33333333333334],PARAMETER["Standard_Parallel_2",46.0],PARAMETER["Latitude_Of_Origin",43.66666666666666],UNIT["Foot",0.3048]]
For those who might have the same problem, in the course of answering this question (r/gis/reddit proved the most useful) I learned:
There are local coordinate systems which might not show up on Arc or Q. In this case, the data was derived from a CAD file, a DWG that I converted for a project.
One can change the data frame projected coordinate system within Arc trying to find a fit. In this case there was none, no matter how long or hard I tried
Some Coordinate systems are simply so local they aren't useful, or as a redditor put it, "garbage", so don't waste your time trying to make them fit.
4.The Spatial Adjust tool can be used to effectively georeference a dataset with an unknown coordinate system to one which is known. So in my case, I took the .shp and then used the spatial adjust toolset to "rubbersheet" it to some clearly defined data. Easy. Took a few minutes. Made it fit, defined projection, called it good.
I'm currently working on project that uses json file with points & polygons.
All input data are a Lat/Lon format. I wish to draw these on a map (Which should be able to pan). I'm able to draw these objects on a JavaFx Pane or Canvas.
The issue is the data line between two coordinates is a straight line while it actually should follow stereographic projection .
I looked into ArcGis and other GeoTools but these tools all build upon tile maps something I don't need for my project.
You will have to create something what we call a LineDrawer. First you have to determine what line type you want to use. Standard line types are great-circle, rhumb and just straight lines. Second you have to define the projection you want to use. So if you now want to draw a line between two points A and B you have to split this up into small enough sections and compute intermediate points according to the formula for your chosen line type and then you have to project these points into your drawing pane.
But that's basically what every GIS software can do for you and you don't have to re-invent the wheel here.
I am trying to render a mvt (Mapbox Vector Tile) containing OSM data using Mapbox GL js, but I keep getting some ugly polygons like they were simplified (like in the Simplification section of this documentation!). I don't want those polygons to be simplified. At least I would like the best resolution to be as close as possible from reality.
First, I checked if it could come from OSM data. But OSM data is good.
So I looked into the tile server and more precisely into the mvt encoder (code). The extent value, which controls how detailed the coordinates are encoded in the vector tile, is 4096. 4096 is a very good value. So I don't understand why I don't get proper polygons.
I suppose that this issue comes from Mapbox GL js which might perform an additional simplification.
What extent value could I use in the encoder?
Is there a way to configure a resolution with mapbox gl js ?
I would appreciate some help !
Thanks!
Mapbox GL JS does not do any additional simplification on vector tile sources. If you are seeing simplified geometries, this is most likely done during vector tile generation.
I was finding the same thing. I got better results when, rather than importing the polygons as a geojson as I had been doing, I converted the file to a shape file, zipped it, and imported that into mapbox. There was then no simplification to the shape.
I would like to create a GPS drawing program in Argon and A-Frame which draws lines based upon people's movements.
Lines can be drawn in A-Frame with, for example, the meshline component which uses Cartesian points:
<a-entity meshline="lineWidth: 20; path: -2 -1 0, 0 -2 0</a-entity>
If I were to do this with a GPS device, I would take the GPS coordinates and map them directly to something like Google maps. Does Argon have any similar functionality such that I can use the GPS coordinates directly as the path like so:
<a-entity meshline="lineWidth: 20; path: 37.32299 -122.04185 0, 37.32298 -122.03224</a-entity>
Since one can specify an LLA point for a reference frame I suppose one way to do this would be to conceive of the center LLA point as "0, 0, 0" and then use a function to map the LLA domain to a Cartesian range.
It would be preferable, however, to use the geo-coordinates directly. Is this possible in Argon?
To understand the answer, you need to first understand the various frames of reference used by Argon.
First, Argon makes use of cesiumjs.org's geospatial math libraries and Entity's so that all "locations" in Argon must either be expressed geospatially OR be relative to a geospatial entity. These are rooted at the center of the earth, in what Cesium calls FIXED coordinates, but are also know as ECEF or ECF coordinates. In that system, coordinates are in meters, with up/down going through the poles, east/west going through the meridian (I believe). Any point on the surface of the earth is represented with pretty large numbers.
This coordinate system is nice because we can represent anything on or near the earth precisely using it. Cesium also supports INERTIAL coordinates, which are used to represent near-earth orbital objects, and can convert between the two frames.
But, it is inconvenient when doing AR for a few reasons:
the numbers used to represent the position of the viewer and objects near them are quite large, even if they are very close, which can lead to mathematical accuracy issues, especially in the 3D graphics system.
The coordinates we "think about" when we think about the world around us have the ground as "flat" and "up" as pointing ... well, up. So, in 3D graphics, an object above another object typically has the same X and Z values, but has a Y that's bigger. In ECEF coordinates, all the numbers change because what we perceive as "up" is really a vector from the center of the earth though us, and is only "up" if we're on the north (or south, depending on your +/-) pole. Most 3D graphics libraries you might want to use (e.g., physics libraries, for example), assume a world in which the ground is one plane (typically the XZ plane) and Y is up (some aeronautics and other engineering applications use Z as up and have XY as the ground, but the issue is the same).
Argon deals with this, as do many geospatial AR systems, by creating a local coordinate system for the graphics and application to use. There are really three options for this:
Pick some arbitrary (but fixed) local place as the origin. Some systems, which are built to work in one place, have this hard-coded. Others let the application set it. We don't do this because it would encourage applications to take the easy path and only work in one place (we've seen this in the past).
Set the local place to the camera. This has the advantage that the math is the most "accurate" because all points are expressed relative to the camera. But, this causes two issues. First, the camera tends to move continuously (even if only due to sensor noise) in AR apps. Second, many libraries (again, like physics libraries) assume that the origin of the system is stable and on the earth, with the camera/user moving through it. These issues can be worked around, but they are tedious for application developers to deal with.
Set the origin of the local coordinates to an arbitrary location near the user, and if the user moves far from it, recenter automatically. The advantage of this is the program doesn't necessarily have to do much to deal with it, and it meshes nicely with 3D graphics libraries. The disadvantage is the local coordinates are arbitrary, and might be different each time a program is run. However, the application developer may have to pay attention to when the origin is recentered.
Argon uses open 3. When the app starts, we create a new local coordinate frame at the user's location, on the plane tangent to the earth. If the user moves far from that location we update the origin and emit an event to the application (currently, we recenter if you are 5km away from the origin). In many simple apps, with only a few frames or reference expressed in geospatial coordinates (and the rest of the application data expressed relative to known geospatial locations), the conversion from geospatial to local can just be done each frame, allowing the app developer to ignore the reentering problem. The programmer is free to use either ENU (east-north-up) or EUS (east-up-south) as their coordinate system; we tend to use EUS because it's similar to what most 3D graphics systems use (Y is up, Z points south, and X is east).
One of the reasons we chose this approach is that we've found in the past that if we had predictable local coordinates, application developers would store data using those coordinates even though that's not a good idea (you data is now tied to some relatively arbitrary application-specific coordinate system, and will now only work in that location).
So, now to your question. Your issue is that you want to use geospatial (cesium's coordinates, that argon uses) coordinates in AFrame. The short answer is you can't use them directly, since AFrame is built assuming a local 3D graphics coordinate system. The argon-aframe package binds aframe to argon by allowing you to specify referenceframe components that position an a-entity at an argon/cesium geospatial location, and take care of all the internal conversions for you.
The assumption when I wrote that code was that authors would then create their content using the local, 3D graphics coordinates, and attach those hunks of graphics to a-entity's that were located in the world with referenceframe's.
In order to have individual coordinates in AFrame correspond to geospatial places, you will need to manage that yourself, perhaps by creating a component to do it for you, or (if the data is known at the start) by converting it up front.
Here's what I'd do.
Assuming you have a list of geospatial coordinates (expressed as LLA), I'd convert each to a local coordinates (by first converting from LLA to Cesium's FIXED ECEF coordinates and creating a Cesium Entity, and then calling Argon's context.getEntityPose() on that entity (which will return it's local coordinates). I would pick one geospatial location in the set (perhaps the first one?) and then subtract it's local coordinates from each of them, so that they are all expressed in local coordinates relative to that known geospatial location.
Then, I'd create an AFrame entity attached to the referenceframe of that unique geospatial entity, and create your graphics content inside of it, using the local coordinates that are expressed relative to it. For example, let's say the geospatial location is LongLat = "-84.398881 33.778463" and you stored those points (local coordinates, relative to LongLat) in userPath, you could do something like this:
<ar-scene>
<ar-geopose id="GT" lla=" -84.398881 33.778463" userotation="false">
<a-entity meshline="lineWidth: 20; path: userPath; color: #E20049"></a-entity>
</ar-geopose>
</ar-scene>
these vector or raster files being classic files without geocoordinates. They are lat/long projection, I want to import them into QGIS, scale them up/down, place them to their right place, and they become reusable shp or raster geocoordinated layers.
Edit: I'am from the wikipedia Graphic Lab>Map workshop, we want to work more using GIS. We litteraly have hundreds maps to migrate to GIS technologies....
File:Chinese_plain_5c._BC-en.svg
File:Vignobles_basse_loire.svg
Partial Solution: load SVG into Inkscape, Save as DXF file, then you can load this into QGIS. This should at least get you most of the linework into QGIS.
However, it won't yet be properly georeferenced or styled, and different layers may be in different places because the SVG has some scaling and translating operators on parts of the map data that QGIS or Inkscape is ignoring. You'll probably need to work with a layer at a time. This probably isn't a problem since maybe you are only interested in the added data on the map, and not the base map (country outlines etc) since you will probably want to overlay your data onto standard map base layer (natural earth, OpenStreetMap tiles).
The only way I see to do the transformation at present is to work out the affine transformation parameters and use the QgsAffine plugin, but that does require you to work out the parameters beforehand by fitting known source coordinates to known target coordinates.
But to do hundreds? You might be better off writing some custom SVG parsing code for each one...
If you only want to display it in the correct place, scale and rotation treat it as an SVG icon.
1. create a point layer and put a single point at the georeferenced centre of the SVG you will load.
2. edit the symbology and load the SVG as an icon
3. set the size units to map units
4. supply the appropriate dimensions
5. rotate as necessary
The redraw is very slow and painful, but if you use Project>import/Export>Export map as image you can make a georeferenced raster.