2.1.0.25 (PreRelease)

[Darren Clemons]

Installed the pre release first thing this morning. At first, everything was fine. Installed, rebooted fine and coordinates of current job were in Ky Single as they were supposed to be.
It just so happened, the first thing on my list today was something back on an old job. I found and unpacked the archive of that job and when I went into coordinates of it, they were all screwed up again - back to just Lat/Long - no coordinate transformation.
I then went back into the job that had looked ok after update and now it was the same - no Ky Single zone coordinates.

This has got to be back on the genmapsdata.dbf file I've had so much trouble with - it happens with unpacked archived jobs and with the "duplicate" coordinate systems of KYsinglezone (12.11.17 where it applies a date to the end of the crd system).

I deleted the old unpacked job - rebooted and just started a "new" job and imported the raw coordinates from Autocad and everything is fine (I think )

Just sent Scott out to two jobs - will find out soon if all's OK.

 

[Matt Johnson]

It seems there was some incompatibility of the coordinate systems from the old project archive. How old is that project? Also can you share its project archive, you can email it to me if you want.

 

[Darren Clemons]

It seems there was some incompatibility of the coordinate systems from the old project archive. How old is that project? Also can you share its project archive, you can email it to me if you want.

Not that old, maybe three or four months. Every single time I’ve had the “cannot read db” issue and had to delete the genmapsdata file it’s been caused by unpacking older projects.

I didn’t get any calls from field crew today so I’m guessing everything went ok with the pre release version I installed this morning.

I’ll send the project archive of the job I unpacked to you in the morning Matt, but I honestly don’t think it’s anything extremely specific to this one particular job.

I think it has something to do with any/every job I unpack from an archive. If I don’t watch and delete “old” coordinate systems I can end up with several Ky Single Zone “duplicate” systems. Each are identical except the “original” has no date attached. Every single job I unpack from an archive will have the date that I unpack attached to the crd system AND it will make its own additional entry in the list of coordinate systems. Still not sure why and what purpose there is for this.

I had a lot of issues with having to delete the genmapdata file over and over, but since I’ve started keeping every “duplicate” crd system deleted as soon as I finish with the unpacked archived project which created it, I hadn’t had it happen once in over a month - until this morning.

 

[Greg Flowe]

I loaded 2.1.0.25 this weekend and used it today on the NC RTN with no issues. Just had to reset some of my white boxes though after loading the new program.

 

[Vladimir Prasolov]

Hi Darren,
Could you send both projects please. We will try to reproduce issue and fix it. All GeoData releases are fully backward compatible. So I think it is some kind of conflict between original and duplicate systems.

 

[Matt Johnson]

Hi Darren,
Could you send both projects please. We will try to reproduce issue and fix it. All GeoData releases are fully backward compatible. So I think it is some kind of conflict between original and duplicate systems.

I have attached Darren's project. When I import it into my LS I am not able to replicate the problem with the coordinate system not loading.

Darren I saw that you are using some random epoch (2015.4922) in this coordinate system. It should be set to 2010. Also you are not using the latest geoid model which is GEOID 12B (ConUS).

Maybe @Mikhail Drakin can address the issue of duplicated coordinate systems when unpacking projects? Ideally I don't think we should create a duplicated coordinate system with the date appended to the name if an identical coordinate system (same Transformation, Height System, and Epoch) already exist in the database.

 

[Shawn Billings]

@Matt Johnson you'll recall that early on, when a coordinate system was created in NAD83(2011) the default epoch was the date of its creation in J-Field, whatever date that may have been when the customer created the system in his LS. I would have to search to find out when we made the default properly 2010 by default.

 

[Matt Johnson]

Yes but somehow this old input epoch from 2015 has survived to be in a new project created July of this year. This issue was addressed in J-Field over a year ago so that 2010 is the default now.

 

[Shawn Billings]

I'm pretty sure that even now, it is the default at the creation of the system. If he never had need to create it again, it would still have the same epoch date as when he created it initially.

 

[Darren Clemons]

I didn't notice that yesterday, but Matthew Sibole had noticed a while back I had not had my epoch set at the default 2010 and I deleted those "old" crd systems and created new ones with the proper 2010 epoch attached and Geoid 12b.
This must've been created prior to me addressing that - and "could" be a big part of why certain jobs I unpack cause the genmapsdata bug???

 

[Matt Johnson]

I didn't notice that yesterday, but Matthew Sibole had noticed a while back I had not had my epoch set at the default 2010 and I deleted those "old" crd systems and created new ones with the proper 2010 epoch attached and Geoid 12b.
This must've been created prior to me addressing that - and "could" be a big part of why certain jobs I unpack cause the genmapsdata bug???

This would not be why. Have you preformed a factory recovery recently on this LS? If you are having to delete GenMapsData often than the internal memory may likely need to be reformatted.

 

[Darren Clemons]

This would not be why. Have you preformed a factory recovery recently on this LS? If you are having to delete GenMapsData often than the internal memory may likely need to be reformatted.

I had to do a factory recovery last week when I first installed the new update.
I haven't had to delete the .dbf often lately - it was back two or three months ago where I had it happen three or four times in a matter of a week....It was then I noticed I had several pages of those "duplicate" crd systems. I deleted all the crd systems, re made my Ky Single and Ky South that I normally work in (selecting 2010 epoch) and had since not had the .dbf issue.

Also, this is actually a rental unit I've only had a couple weeks while mine is in for an RMA....

 

[Mikhail Drakin]

@Vladimir Prasolov will address the unpacking of projects, currently he creates CS duplicate if another copy already exists in genmapsdata (that's why deleting genmapsdata helps until another project with that CS is opened).

 

[Adam]

I notice the stop button doesn't work in mag screen anymore.

 

[Darren Clemons]

Been using this pre release version now over a week with no issues.....