This is all just my opinion but here are my 2cents worth, but yes you are on the right track.
It really depends on the asset type you are capturing for a start and what kind of information you are planning to collect, and how much time you have to train people etc. Generally I prefer the PDA route as it allows faster information processing and cuts the middle man out in a effort to remove the chance of mistakes in data entry.
The PDA route is not a bad option and it's a shame that you hitting heavy criticism with it but it happens I guess.
If you are on a WM and MapInfo there is GBMMobile which you can use the inbuilt/external GPS to capture points and it will also handle using the onboard camera and attach the photo to the point for you.
There is also a open source PDA program: http://www.gvsig.org/web/projects/gvsig-mobile/tour/image-gallery/ but I have never used it so I can't tell you how good it is.
The biggest problem we have had is finding good and stable PDAs with GPS and Cameras, you can buy rugged ones but they range about $1500-$3000+.
Depending on the asset type we have taken a few different tactics, this is due to having a small GIS/Asset team.
We have both PDAs and a GPS enabled camera, for simple assets we tend to use the GPS enabled camera. We get someone to go out and take photos of the assets, I then strip out the GPS coordinates with a MapInfo based program I wrote, I then have a piece of software that someone in the office can sit down and go though the photos and give the point some more data eg Asset Type, Condition. Of course this only works for really simple assets that don't really require measurements (play eq, park seats, bins are a good for this).
The second way is to use a PDA with GBMMobile to capture the asset and fill out the information out in the field, for more detailed stuff.
The third way is to capture the points with GPS, give them a asset number and then print out a map and some forms to capture the information and give it to a field crew. We use this option to capture inverts and manhole conditions for our sewer network. We use paper here because we couldn't find any software that really did what we needed(well) and the crews work on and off this project and the last thing they need to be worried about is a electronic device stuffing up in the middle of a job.
Pros:
- Faster data entry
- Avoid data entry mistakes in the office from paper eg Bad spelling, incorrect values.
- Can use form validation eg Downstream can't be higher then upstream.
- Pictures for asset types rather then codes
- GPS position and picture(on selected models) of asset at once.
- Quicker office processing - bring PDA in. Sync. Done.
- Map of existing assets and numbers at fingerer tips.
Cons:
- Cost.
- Training.
- Finding good software.
- Getting past resistance of people used to paper.
- Keeping them charged.
- Keeping them all up to date.
My general advice is it is a good way to go, but start small and grow out. Don't try and roll a heap of them out to field crew straight away or you will have more resistance and non-compliance, then you will have no data at all.
Very interesting problem. There are many questions here so I'll give my shot at one. There is such a thing as real-time differential GPS. When we did NASA flight tests, we sent an engineer up to our landing site to setup up the GPS station ahead of the airplane. The station was placed at a known accurate location and broadcast corrections to a GPS receiver on the airplane correcting our position data during the flight. As the airplane approached the airfield (where the station was located), we could begin obtaining DGPS on the first approach. So, we could get good enough accuracy to auto-land an airplane.
If you really need meter/sub-meter accuracy, then DGPS is going to be (at least part) of your solution.
Best Answer
Those messages correspond to the old NMEA 0183 specification. Which more than amended was replaced by NMEA 2000, that is very different and is not an ascii serial communication, it is basically a completely different beast. However NMEA 0183 is still in use and supported by many devices. And the two digit year just roll over. Therefore, year 2000 is represented as 00 and 2018 as 18. Here is an example of a chunk of NMEA output recorded by myself some years ago:
You can see that the timestamp is 090210, which was indeed February 9th 2010.
Thankfully, there is no ambiguity in the data because there was no GPS nor NMEA back in 1910. The First NMEA protocol was NMEA 0180, with the "80" in "0180" meaning 1980 (3), so you can be confident that any value below 80 corresponds to this century. The problems are going to start in 2080, but thankfully that is still a long way ahead.