Topic: Open Source Survey Package?

[MP]

Good stuff Troy.

As xml is self describing it might indeed be a good for the reasons I briefly touched on (point adornment etc.). While, at this point, it may be overkill, I see nothing wrong with having the capacity to store what the current identified needs are (wait have they been identified?), rather, the problem is when a container or spec cannot host future unknown requirements.

While one might guess I'd now say "yeah, has my vote" no, I say -- "this worthy serious consideration, put it on the list of proposed formats and let us go now and identify what actually needs to be stored now as an absolute minimum, and what possibly be required for the future" -- which should be done first.

Rhetorical and not so rhetorial questions: What are the deliverables? What is the workflow? What minimum data do we need to start with?

Insomnia -- it's a lot more than lack of sleep.

[MP]

Whatever format most surveying instruments spit out is the format we need to support for input files.

Once the point data is imported, I think the dwg format should be able to accommodate all of our needs.

At the dll level, assuming that's the route were going (which has not been finalised or even formally truly floated) it's just the core math -- they know nothing (and should not know) how the data is to be used or stored -- they simply accept input, perform calculations and return results, but are (or should be imo) application agnostic.

/imo

[Mark]

For me a typical csv file would contain: PointNumber,Northing,Easting,Elevation,Description

Unless I'm missing something that should take care of any thing you'd want to do in a survey.

From all the packages I've used that have the ability to write a csv file, none would have a problem with this format. ( PointNumber,Northing,Easting,Elevation,Description )

[MP]

Good stuff Mark.

Like I said previously, I really don't know a thing about the requirements for a survey program. I'm just trying to contribute the only way I think I can: Ask the questions that have to be asked, throw alerts on things that don't look right, suggest methodologies that have worked in the past. As most of these things are not application centric, to that end I think I have something to contribute, if nothing other than my bent on sanity checks (which by definition is absurd, oh well).

[Mark]

Typical workflow for us is; instrument--> data collector --> PC --> adjustment application --> point file --> CAD/Enginerring application.

I've never seen data come from a total station directly into CAD, I'm not saying it doesn't happen though.

[Chuck Gabriel]

Whatever format most surveying instruments spit out is the format we need to support for input files.

Once the point data is imported, I think the dwg format should be able to accommodate all of our needs.

At the dll level, assuming that's the route were going (which has not been finalised or even formally truly floated) it's just the core math -- they know nothing (and should not know) how the data is to be used or stored -- they simply accept input, perform calculations and return results, but are (or should be imo) application agnostic.

/imo

I think you and I are in agreement, but apparently I'm just not expressing my ideas clearly enough.  It sounds to me like you are saying the same thing I'm thinking, but evidently the reverse isn't true.

[Swift]

For me a typical csv file would contain: PointNumber,Northing,Easting,Elevation,Description

Unless I'm missing something that should take care of any thing you'd want to do in a survey.

From all the packages I've used that have the ability to write a csv file, none would have a problem with this format. ( PointNumber,Northing,Easting,Elevation,Description )

This is true and correct and is the established way in my area of exchanging data between companies and clients. Only stipulation that some packages place is a 32 character limit on the Description field.

That said I will bring to light the LANDXML project at http://www.landxml.org/ and https://sourceforge.net/projects/landxmlsdk/

[MickD]

Just my opinion, while I think XML is a great tool for storing data, you still need to use a parser. This applies unwanted overhead and complexity to your app. It seems to me from what has been said so far that a csv file is pretty basic, universal and easy to export/import into other apps, to write a parser for this type of csv would be pretty simple and fast to implement with no COM or other unwanted baggage.

[Dinosaur]

Who will the end users of this package be?  I would expect most of them to be guys with older equipment and software that almost certainly will be able to export simple text files as Mark describe but would be much less able to work with other formats and some, such as our surveyor, who refuse to use other methods when they are available.

[Swift]

Just my opinion, while I think XML is a great tool for storing data, you still need to use a parser. This applies unwanted overhead and complexity to your app. It seems to me from what has been said so far that a csv file is pretty basic, universal and easy to export/import into other apps, to write a parser for this type of csv would be pretty simple and fast to implement with no COM or other unwanted baggage.

All that's true, but once we start doing more advanced things like horizontal/vertical alignments, typical sections, cross sections, profiles and dtms then we will need a more defined format such as LandXML. So if we will need it in the future, shouldn't the project be started using it?

[Bob Wahr]

I am about 40 posts behind right now and will probably do my catch-up tomorrow.  Don't have a lot of time so I'm going to combine the two threads.  The more platform independant it is, the better IMO.  I think it would be great if it worked on intellicad and autocad.  Has anyone mentioned MicroSuction?  If I remember right, intellicad is open source, what about a Swamp Civil build of intellicad with this bundled?  While there are, in my mind, reasons such as ease of design to avoid XML, I think LandXML still might be the way to go.  I have seen federal contracts that require LandXML data.  More to follow, probably much more.  Anyone who knows me, knows that while I may be short on abilities, I'm never short on opinions.

[Dent Cermak]

Another thing to remember on the coordinate files is that while PNEZD is the format that most of us use, MANY large companies request Point . X. Y, Z,Desc. (Or PENZD) and then you must also be able to create space delimited and comma delimited files. Some data collectors take one, some take the other. If you cannot download your final coordinate file back into the data collectors to complete the field work, you do not have a viable product.
And don't forget the traverse balancing routines. You will need to be able to balance by Compas Rule, Crandal's Rule and Least Squares at a minimum to meet all state requirements. (Lately Least Squares is more and more becoming the prefered method.
And if this thing is going to include a Terrain Package I have a long wish list there too.

[Swift]

The thing about balancing routines is importing the various raw data files. I have all the math for Compass, Crandals and Least Squares routines. In fact I already have the least squares solver written,just so happens the method is the same for coordinate transformations, the only difference is the content of the matrices it solves. I however will need some help reducing the calculus involved if I can't find all of my work from college.

I have samples of SMI versions 3-6 and Carlson SurvCE raw data files. We will eventually need samples for all packages we will need to support. We also will need someone with access to various adjustment packages for checks.

On another note I can also adjust GPS Vectors if there is a need for it and level loop adjustments aren't a big deal either.

[jonesy]

Can I be nosey and ask what this proggy would do?

When our office is running/I'm back at work, could I send you a file that our MX people get from the surveyors? and then see if it the sort of proggy you guys are working on?

Many thanks
T

[Murphy]

I have a 2 year degree in surveying and have forgotten most of it.
From what I have read it sounds like the push in the future is XML.
But, the instruments will only take csv or ssv files in certain formats.
Sounds like you should build the whole thing around XML and make an import/export routine that will deal with csv and ssv files. Go so far as to ask the user if it is in PNEZD or PENZD. That sounds like it would be the more robust of the options AND make it future friendly as well.

Let me know what I can do to help.