Joe Paulin
Well-Known Member
When exporting shapefiles out of JField, it produces three files: a .shp, .shx & a .dbf. Could the developers add an OpenGIS-compatible .prj file as well?
Shapefile exports
- Thread starter Joe Paulin
- Start date
Joe Paulin
Well-Known Member
Andrey, I don't understand your reply above. When I click on the link you posted, it says that I don't have the right permissions to view it.
This links a hidden discussion board. The sum up in that discussion (where we asked for prj export) was:
Also, I've [Mikhail Draken] discussed the question of saving PRJ files with Vladimir Prasolov and he confirmed that while it will in any case take too much effort to implement, PRJ files cannot reflect all capabilities of our coordinate transformation engine, so it doesn't make much sense anyway. It is better to use workaround with placing pre-created PRJ near shapefiles when it's applicable.
There are aspects of some of our coordinate systems that the prj format can't handle.
Also, I've [Mikhail Draken] discussed the question of saving PRJ files with Vladimir Prasolov and he confirmed that while it will in any case take too much effort to implement, PRJ files cannot reflect all capabilities of our coordinate transformation engine, so it doesn't make much sense anyway. It is better to use workaround with placing pre-created PRJ near shapefiles when it's applicable.
There are aspects of some of our coordinate systems that the prj format can't handle.
I have to chime in on this.
I have used Shape files since the early 1990's with numerous GIS, Navigation, and Surveying software packages.
I still use them when necessary, and while they may be a legacy file format, and have been superseded by better file formats
they are still ubiquitous, and will remain so for a very long time.
Supporting this file format with the exportation of the four primary files (.shp, .shx, .dbf, and .prj) would seem to me to be the
proper thing to do.
I have had this discussion with other software developers when their software exported shape files without the .PRJ file.
They also used a similar reason for not exporting the .PRJ file (.PRJ file limitations).
This led to my asking this question.
"If you are unable to export a .prj file with the shape file, how are you able to import a shape file properly, and what coordinate system is it using when
you import the file? Is the software creating a new coordinate system on the fly when the .PRJ file does not exactly match the desired coordinate system?"
You can see where I have taken this argument, but I will stop here.
I would suggest adopting the EPSG definitions for the .PRJ file coordinate systems when exporting from Javad to a shape file.
These definitions can be stored internally on the LS as a text file, or in a database, and cross referenced to the best fit system upon project creation.
I am going to assume Joe Paulin is working in one of the many North American Projections, probably one of the versions of NAD83, all of which are defined
by the EPSG.
I understand the challenge.
4600 plus coordinate zone definitions in the latest version of PROJ https://proj.org/
Some are redundant, and even erroneous, but they are there, and freely available.
My personal preferences would be support of the SpatiaLite https://www.gaia-gis.it/fossil/libspatialite/index
or Geopackage https://www.geopackage.org/ file formats.
Both SpatiaLite, and Geopackage are Open Source, freely available, well defined, and for the most part very stable.
They also use the EPSG definitions for coordinate zone parameters.
These file formats are also operating system agnostic, as are PROJ, and GDAL (www.gdal.org) both of which could be incorporated into JField, and JMT
no matter the operating system.
I also, sincerely hope you never attempt to support the ESRI File Geodatabase format.
Now, with regards to my methodologies for exporting data files from the Triumph LS to the GIS software packages of my choice.
I use Comma Separated Values files, and export points with a bunch of attributes. I have connect codes which will assist in drawing the lines I desire
based upon code, Point ID sequence or time sequence. This goes very quickly, and I am able to create a watch file which automatically updates the file
with new data when collected.
There is a great deal more control available to query the data to get the results I desire than what I find in most CAD or Surveying software packages.
Just one fools opinion, and I am probably wrong.
I have used Shape files since the early 1990's with numerous GIS, Navigation, and Surveying software packages.
I still use them when necessary, and while they may be a legacy file format, and have been superseded by better file formats
they are still ubiquitous, and will remain so for a very long time.
Supporting this file format with the exportation of the four primary files (.shp, .shx, .dbf, and .prj) would seem to me to be the
proper thing to do.
I have had this discussion with other software developers when their software exported shape files without the .PRJ file.
They also used a similar reason for not exporting the .PRJ file (.PRJ file limitations).
This led to my asking this question.
"If you are unable to export a .prj file with the shape file, how are you able to import a shape file properly, and what coordinate system is it using when
you import the file? Is the software creating a new coordinate system on the fly when the .PRJ file does not exactly match the desired coordinate system?"
You can see where I have taken this argument, but I will stop here.
I would suggest adopting the EPSG definitions for the .PRJ file coordinate systems when exporting from Javad to a shape file.
These definitions can be stored internally on the LS as a text file, or in a database, and cross referenced to the best fit system upon project creation.
I am going to assume Joe Paulin is working in one of the many North American Projections, probably one of the versions of NAD83, all of which are defined
by the EPSG.
I understand the challenge.
4600 plus coordinate zone definitions in the latest version of PROJ https://proj.org/
Some are redundant, and even erroneous, but they are there, and freely available.
My personal preferences would be support of the SpatiaLite https://www.gaia-gis.it/fossil/libspatialite/index
or Geopackage https://www.geopackage.org/ file formats.
Both SpatiaLite, and Geopackage are Open Source, freely available, well defined, and for the most part very stable.
They also use the EPSG definitions for coordinate zone parameters.
These file formats are also operating system agnostic, as are PROJ, and GDAL (www.gdal.org) both of which could be incorporated into JField, and JMT
no matter the operating system.
I also, sincerely hope you never attempt to support the ESRI File Geodatabase format.
Now, with regards to my methodologies for exporting data files from the Triumph LS to the GIS software packages of my choice.
I use Comma Separated Values files, and export points with a bunch of attributes. I have connect codes which will assist in drawing the lines I desire
based upon code, Point ID sequence or time sequence. This goes very quickly, and I am able to create a watch file which automatically updates the file
with new data when collected.
There is a great deal more control available to query the data to get the results I desire than what I find in most CAD or Surveying software packages.
Just one fools opinion, and I am probably wrong.
Joe Paulin
Well-Known Member
Let me provide a little context on why I am asking. I love the kml google earth export option in JField, I use it for every job. Once in Google Earth when you click on a point, the description, code and attributes display nicely. I use it as a point viewer and Google Earth presents the points in a clean easy presentable manner. It can also be given to clients.
That said, when you export shapefiles out of JField, the points carry a ton more attributes: positional quality indicators, antenna height, duration of shot, # of sats used, etc. But I have yet to figure out how to EASILY get this data viewable in a CAD platform like Carlson or Civil 3D. You can do it, but the way the data is presented isn't easily viewed or cleanly presented. I posted on this a while ago - getting this point attribute data into C3D.
So I thought the next best thing would be to import the shapefile into Google Earth for viewing. But when importing, GE needs a .prj file to work, hence my request.
Could the Google Earth export option in JField be expanded to include all this metadata? Maybe have two options: one to show just description, code & attributes and another to show all the technical attributes as well?
That said, when you export shapefiles out of JField, the points carry a ton more attributes: positional quality indicators, antenna height, duration of shot, # of sats used, etc. But I have yet to figure out how to EASILY get this data viewable in a CAD platform like Carlson or Civil 3D. You can do it, but the way the data is presented isn't easily viewed or cleanly presented. I posted on this a while ago - getting this point attribute data into C3D.
So I thought the next best thing would be to import the shapefile into Google Earth for viewing. But when importing, GE needs a .prj file to work, hence my request.
Could the Google Earth export option in JField be expanded to include all this metadata? Maybe have two options: one to show just description, code & attributes and another to show all the technical attributes as well?
Have you exported a dwg file with the points? It carries many of the attributes you are referring to. Just look at the point attributes.
Joe Paulin
Well-Known Member
If I recall, when I tried that a while ago the points didn't have nodes in the drawing which was why I steered away from that approach. I will revisit that method again though, thanks for the suggestion.
Joe Paulin
Well-Known Member
Shawn,
The dwg export has all this great stuff in it, click on the point and all the attributes are in the properties box, which is great, just what I want. But in the drawing, it is a block, not a point. I need to convert these blocks to points... Carlson points or C3D points so that they can be worked with just like points created from importing a txt file. Can this be done? Does anyone know how?
The dwg export has all this great stuff in it, click on the point and all the attributes are in the properties box, which is great, just what I want. But in the drawing, it is a block, not a point. I need to convert these blocks to points... Carlson points or C3D points so that they can be worked with just like points created from importing a txt file. Can this be done? Does anyone know how?
John Thompson
Well-Known Member
+1 on making blocks in the dwg file into points. Or making J-Field export a Carlson .crd file with all the properties.
Crd is a five field format, is it not? I don't believe it's capable of containing all of the properties.
John Thompson
Well-Known Member
Hmm. I just learned something. All those point notes that I thought were stored in the .crd file are actually stored in a .not file with the same name. Maybe J-Field could write a .crd file with an accompanying .not file.
Isn't a not file an ascii file? I'm guessing you can create one by custom export now.
John Thompson
Well-Known Member
The .rw5 file does not have all the point properties that the .dwg file shows. I thought maybe I could create a .crd by reprocessing the .rw5 file with Carlson Survey, but the info is not there.
As for creating a .not file by custom txt export, is it possible to export the field names with each point (not just a header row)? If I look at the block attributes of a point in the .dwg file, I see something like this.
Duration 10
Epochs 51
GLONASS Count 5
GPS Count 8
If I export the same as txt, the same data looks like this.
10,51,5,8
Maybe making the .dwg blocks into points is the best option.
As for creating a .not file by custom txt export, is it possible to export the field names with each point (not just a header row)? If I look at the block attributes of a point in the .dwg file, I see something like this.
Duration 10
Epochs 51
GLONASS Count 5
GPS Count 8
If I export the same as txt, the same data looks like this.
10,51,5,8
Maybe making the .dwg blocks into points is the best option.
I think the easiest and best solution is to also export a text/csv file from J-Field with the points and then import these into your Carlson .crd file. If you want to export both the text/csv file and dwg file at the same time you can use Batch Export.
I would recommend using QGIS, and importing a .csv file if you want a fully populated drawing/database file will every attribute you desire.
From there you are able to export DXF, Geopackage, KML (With attributes), Shape, Spatialite, PostGIS, and a myriad of other file types.
The software is free, supports multiple operating systems, and is very easy to learn. QGIS.org
Yeah, it is not CAD, but it has plenty of CAD capabilities, works very well with State Plane Coordinate systems, and imagery or all types.
It can generate contours from DEM's, or points, as well as irregular point grids, and the spatial analysis capabilities leaves most CAD packages wanting.
My lack of familiarity with the format of the .crd & .not files keeps me from making an educated comment here, but I believe you would be able to join the two files
in QGIS after importing them as .txt or .csv files so long as they had a common identifier field.
From there you are able to export DXF, Geopackage, KML (With attributes), Shape, Spatialite, PostGIS, and a myriad of other file types.
The software is free, supports multiple operating systems, and is very easy to learn. QGIS.org
Yeah, it is not CAD, but it has plenty of CAD capabilities, works very well with State Plane Coordinate systems, and imagery or all types.
It can generate contours from DEM's, or points, as well as irregular point grids, and the spatial analysis capabilities leaves most CAD packages wanting.
My lack of familiarity with the format of the .crd & .not files keeps me from making an educated comment here, but I believe you would be able to join the two files
in QGIS after importing them as .txt or .csv files so long as they had a common identifier field.
Joe Paulin
Well-Known Member
Carlson has a newer point format out there, I am just getting acquainted with it. It sounds like it can handle attributes, is it possible for JField to have a .CRDB export?
This from the Carlson Help on CRDB: The CRDB file format is based on SQLite structures. The CRDB format contains the same data as a CRD format but with extra information like GIS data and photos links.
Joe Paulin
Well-Known Member
I will have to take a look at QGIS, thanks for the info.
Joe Paulin
Well-Known Member
With QGIS I am able to get all of the additional point metadata (not just code and attributes) into google earth, thanks for the tip Jon. The workflow is as follows: export a shapefile from JField, open it it with QGIS, export a .kml from QGIS and then open it with Google Earth. Nice.
With this methodology, I could have CAD open on one screen and GE open on another screen when working. To keep point description clutter to a minimum in cad, in JField export a text file of your points in the format of P,N,E,Z,C where C is your code. Then, if you need to see the point attributes or more technical information about that point, simply select it in GE to get all the metadata.
It would be amazing if Javad developers could team up with Carlson developers to make this happen seamlessly within Carlson. That would be the best situation - select a Carlson point and all the attributes pop up in the properties dialog box. From the feedback here, I am not the only one who sees value in this.
With this methodology, I could have CAD open on one screen and GE open on another screen when working. To keep point description clutter to a minimum in cad, in JField export a text file of your points in the format of P,N,E,Z,C where C is your code. Then, if you need to see the point attributes or more technical information about that point, simply select it in GE to get all the metadata.
It would be amazing if Javad developers could team up with Carlson developers to make this happen seamlessly within Carlson. That would be the best situation - select a Carlson point and all the attributes pop up in the properties dialog box. From the feedback here, I am not the only one who sees value in this.