TOWGS84 in PROJ.4 support datums transformation from another datum to WGS84 datum.
Could anyone please give me the list of datums which supported in this method.
The +towgs84 parameter accepts 3 or 7 double precision values describing the datum transformation. If you want to assign datum by name, you have to use +datum, i.e +datum=clrk80. Complete lists of datums and their names are located in nad/ directory of Proj4 in files EPSG, world, ESRI, etc.
Related
folk,
I'm trying to develop something for our Crystal Reports that generates an EAN barcode image from the numeric string.
I've already developed a function in our SQL database to encode the numeric string as the ones and zeroes that represent the bars and spaces but I'm at a total loss as to:
How I would store this in the DB (other than a VarChar(100))
How to translate these ones and zeroes to an actual image (even if only 1 pixel in height)
Much obliged.
You can use a library such as ZXing.
Another option, given that you are looking for an image rather than font solution, is to use a Crystal Reports UFL (User Function Library). Ken Hamady maintains a list of 3rd-party UFLs here.
At least one of those UFLs caters to many types of barcodes, including EAN.
I cannot convert correctly binary numbers to decimal using ASN.1 compilation. Those binaries correspond with lat and long.
lat 1001110010100100101010110011111
long 01101100100101011100100100111000
If I convertem to decimal I get 1314018719 and 1821755704, respectively. However, the coordinates should be this:
enter image description here
I've tried multiple converters but without exit. Any clue?
I don't how you think the encoding works. ASN.1 PER is specified by ITU-T X.680 and ITU-T X.691. (UPER is unaligned PER, a variant of PER defined in the same specs.) The rules for integers include doing things such as encoding as an offset from a lower bound, using a length determinant and minimal octets, using a fixed number of octets and no length determinant, etc., depending on the INTEGER type's constraints. Nobody can tell you how to treat the data you've provided without having the ASN.1 schema and knowing what part of it relates to this data, as well as knowing whether the bits you have include the length determinant or not (if there is one).
Recently, I was studying spatialite.I can write 2D data(like this:POINT(1 1)) into the spatial data table,but I can't write 3D data(like this:POINT(1 1 1) ) into the spatial data table.
Who can tell me spatialite whether support 3D? If support ,how can I write a 3D data?
Yes, Spatialite supports 3D geometries (actually 2.5D geometries).
On why it does not work for you, probably your geometry column is not defined as XYZ. You can check geometry metadata with the query:
SELECT * FROM geometry_columns;
To add points with three 3 dimensions you have to use the correct WKT expression: POINTZ(x,y,z).
(see also: https://www.gaia-gis.it/gaia-sins/spatialite-cookbook/html/wkt-wkb.html)
You also have to make sure, that you geometry column is correctly defined as XYZ column. (see functions: Dimension CoordDimension Is3D). GeometryType should therefore return POINTZ
(see also: http://www.gaia-gis.it/gaia-sins/spatialite-sql-4.2.0.html)
I am having trouble understanding ST_GeomFromText. It looks like there are 3 sets of 2 numbers. Why is that? Wouldn't coordinates just consist of a latitude and longitude?
Here is an example from http://postgis.net/docs/ST_GeomFromText.html:
SELECT ST_GeomFromText('LINESTRING(-71.160281 42.258729,-71.160837 42.259113,-71.161144 42.25932)');
ST_GeomFromText() takes a WKT expression of a geometry object and
Constructs a PostGIS ST_Geometry object from the OGC Well-Known text representation.
The WKT expression in the example is a LINESTRING which is
a one-dimensional object representing a sequence of points and the line segments connecting them.
You might think a linestring would be two-dimensional, but it's not, because a line has no width or height. (Points are 0-dimensional, polygons are 2-dimensional).
So, by definition, that would have more than one set of coordinates. A pair of coordinates would be a POINT, not a linestring, and would look something like this, in conjunction with the function in question:
ST_GeomFromText('POINT (30 10)');
You may want to read up on some GIS fundamentals:
http://www.cise.ufl.edu/~mschneid/Service/Tutorials/TutorialSDT.pdf - excellent tutorial
http://www.opengeospatial.org/standards/orm - OGC Reference Model
I will be storing a year in a MySQL table: Is it better to store this as a smallint or varchar? I figure that since it's not a full date, that the date format shouldn't be an answer but I'll include that as well.
Smallint? varchar(4)? date? something else?
Examples:
2008
1992
2053
I would use the YEAR(4) column type... but only if the years expected are within the range 1901 and 2155... otherwise, see Gambrinus's answer.
I'd go for small-int - as far as I know - varchar would take more space as well as date. second option would be the date.
My own experience is with Oracle, which does not have a YEAR data type, but I have always tried to avoid using numeric data types for elements just because they are comprised only of digits. (So this includes phone numbers, social security numbers, zip codes as well, as additional examples).
My own rule of thumb is to consider what the data is used for. If you will perform mathematical operations on it then store it as a number. If you will perform string functions (eg. "Take the last four characters of the SSN" or "Display the phone number as (XXX) XXX-XXXX") then it's a string.
An additional clue is the requirement to store leading zeroes as part of the number.
Furthermore, and despite being commonly referred to as a phone "number", they frequently contain letters to indicate the presence of an extension number as a suffix. Similarly, a Standard Book Number potentially ended in an "X" as a "check digit", and an International Standard Serial Number can end with an "X" (despite the ISSN International Centre repeatedly referring to it as an 8-digit code http://www.issn.org/understanding-the-issn/what-is-an-issn/).
Formatting of phone numbers in an international context is tricky, or course, and conforming to E.164 requires that country calling codes are prefixed with a "+".