The point value was changed when the point is under meter in c#.

[zhouyang]

Question:
After we insert a single point into a gdb file, and then read the point, we fount the point value was totally changed, seems like the binary of the point was out of the range and was cut off.
For example,
Insert a point(-11120080.721382, 4590945.59778419)
Then, it was read out like (818800.00000000012,818800.00000000012)
we test the upper data with shape.gdb which is from Esri samples(FileGDB_API_VS2010_1_3).

Besides, if we test those points with our gdb file, the result is only the x was cut off, and the y can be read correctly.
Insert a point(-11120080.721382, 4590945.59778419)
Read out point(18435623992.988171,4590945.59778419)

More test:
if we insert the points like (11120080.721382, 4590945.59778419) , (-120, 85), no matter the shape.gdb or our files can read out them correctly.

Recreate the issues:
we create a simple([ATTACH=CONFIG]26413[/ATTACH]) which can show those questions, please have a look.

Thanks advanced.

[MelitaKennedy]

My guess is that the feature class has a spatial reference that includes a geographic coordinate system. The default minimum x value in this case is -400 which is why -120 and the +11million values work (the allowed maximum  x value is very large). Or there's no coordinate system set so the spatial reference default values are just not small enough to allow the -11million value.

Let's see if I can install this...if you are using the shapes.gdb sample and the cities feature class, its spatial reference is using a geographic coordinate systems, NAD 1983. It looks like you want to store, web Mercator, maybe? EPSG:3857? You may need to create a new feature class with that coordinate system first.

Melita

[zhouyang]

Hi Melita,

Thanks for your reply. Please let me know if there is any problem to run my sample.

Actually, we are not very care for the Shapes.gdb, what we are care is the gdb file we created by ourselves have the issue. At the before, we also guess it is related with geographic coordinate system. So we try to change the  SpatialReference's GeographicCoordinateSystem as 900913 in the gdb table definition string like the blow:

GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]

But the result is still not the correct one.
if you open our sample, you can find out the table definition in the XmlTemplate.xml file which includes all the information we defined. Besides, We find if we insert multi-points and then can read them out correctly, no matter how minimum/maximum the x/y is. So, based on this result, we start to doubt if it is really related with the GCS?

what's we expect is would you please run our sample at first and then check if there is any issue in the table definition?
Feel free to tell us if you are asking for any information.
Waiting for your information.
thanks,

[zhouyang]

Here is the partial codes to test multi-point type. it can read out correctly with the table definition I mentioned before.[ATTACH=CONFIG]26452[/ATTACH]

[LanceShipman]

The coordinate reference system for Cites and Cites2 is: GCS_North_American_1983

Unless you have run the sample code, there is no reason to delete any rows from Cities2 as it in empty. The sample code populates Cites2 using the coordinates from City.

I'm reviewing your code.

[LanceShipman]

Use:

<SpatialReference xsi:type="esri:ProjectedCoordinateSystem">
<WKT>PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Mercator_Auxiliary_Sphere"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",0.0],PARAMETER["Standard_Parallel_1",0.0],PARAMETER["Auxiliary_Sphere_Type",0.0],UNIT["Meter",1.0],AUTHORITY["EPSG",3857]]</WKT>
<WKID>3857</WKID>
</SpatialReference>

The WKT and WKID are both required.

[zhouyang]

Thanks PMlshipman,

The new WKT solves our issue. Btw, the WKID node I guess is optional as the value can be read out even without it.

thanks again.

[zhouyang]

Hello guys,

Come back again.:D
I got new issues on FilleGeodatabase GCS. As time goes on, we need to support all kinds of GCS, not only EPSG 3857, however, when we apply those GCS Wkts to the test sample(Attachment 26413)  I sent before. They all failed to create a table. like this:
[ATTACH=CONFIG]26811[/ATTACH]

It seems all the wkts didn't pass the creating validation. So, we did some test and got the below conclusion:
We find the key of the error is the name of the PROJCS. After we change all the wkt's PROJCS's name to "WGS_1984_Web_Mercator_Auxiliary_Sphere" and even without the EPSG number, the table can be built successfully!

So, we are wonder is there any rules on those WKT PROJCS names in FileGeodatabase library? we really want to figure out what's going on before we can support all kinds of WKTs to store those data without be cut off.

Thanks.

Note that: all of the Wkts are generated by our library, and some represented WKTs like the below:

EPSG(3857):
PROJCS["Mercator_2SP",GEOGCS["GCS_unnamed ellipse",DATUM["D_unknown",SPHEROID["Unknown",6378137,0]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Mercator_2SP"],PARAMETER["standard_parallel_1",0],PARAMETER["central_meridian",0],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["Meter",1]]

EPSG(2805):
PROJCS["Lambert_Conformal_Conic",GEOGCS["GCS_GRS 1980(IUGG, 1980)",DATUM["D_unknown",SPHEROID["GRS80",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["standard_parallel_1",42.6833333333333],PARAMETER["standard_parallel_2",41.7166666666667],PARAMETER["latitude_of_origin",41],PARAMETER["central_meridian",-71.5],PARAMETER["false_easting",200000],PARAMETER["false_northing",750000],UNIT["Meter",1],PARAMETER["scale_factor",1.0]]

EPSG(4326):
GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]

[VinceAngelo · Accepted solution]

Please be a bit more careful on the "guys" thing, since the the person from whom
you really want assistance is Melita, eh?

I believe your difficulty is failure to conform to the names on the list of supported
coordinate systems -- the FGDB API does not support custom coordsys values.
If you're going to write your own coordinate systems, you'll need to make sure
they don't have  "unnamed" or "unknown" in the text, and that the names (each
and every name) conform to the supported set.

- V

[MelitaKennedy]

Isn't 'guys' gender-neutral now? 😄

I'm attaching the 10.2 list of well-known ID and text for geographic, projected and vertical coordinate systems. This may be a later version than what's currently in the File Geodatabase API so please double-check that a definition is supported.

Melita