Accuracy of DCW data for placenames?

[Malc]

Hi,

I started playing around with Kuriles Islands/Northern Japan/Russia scenario and after I ran the datas through the DEM2L program, I ended up with a load on NoNames/Nowheres, so I decided to use Google Earth to see if i could start to put names to the places.

After a very short while, it became very obvious alot of the named places were identified incorrectly. At first, I wondered if it was something to do with Zaggy's Russia data, but soon after I found the Japan datas were just as bad - so kudos to Zaggy (again) for not making things worse!

Just curious - has anyone else experienced the same...?

FWIW - I decided to rename everything, so when I'm finished I'll have a pretty accurately named theater. Sad? Yes... No life? Yes... Worth the effort? Absolutely!

Cheers,
Malc

PS - I guess this is a kind of a "Kuriles Theater" announcement... At least I don't have to worry about skinning the aircraft/changing flags, etc. Thanks to Zaggy for the Russian datas and Blueprint for the SRTM terrain datas.

Blue = yet to be renamed Green = accurately renamed

[ccc]

yes there could be many obj named as nowhere and noname.

in old iserali theater, many obj are named as Hoolen city.. i doubt if it ever exist in RL.

i'd suggest you do the rename work for selected, major city/towns of some significance.

glad to hear Kurile theater is revived..any idea to make the campaign working? the theater is similar to Taiwan.. you probably have to set Blue-Red battle on Japan land Hokkido.. or let allied landing on kurile island?

oops- i found my post back in 2000!

http://www.combatsim.com/cgi-bin/ubbcgi ... 1&t=001337

[Snake Man]

I ran the datas through the DEM2L program

You mean through this?

[Zaggy]

At first, I wondered if it was something to do with Zaggy's Russia data, but soon after I found the Japan datas were just as bad - so kudos to Zaggy (again) for not making things worse!

I do try... Cheers...

Just curious - has anyone else experienced the same...?

Yes, I have noticed this in MANY other data sets. To my knowledge the 'errors' arent BIG, but if you know ther terrain, they are ntoicable!

Questions tho, are the names attached to the WRONG Location, or are the Locations themselves out?

What about BIG things like capital cities?

Do these errors occur across ALL forms of point data? ie, Airports AND Place Names?

Im curious...

FWIW - I decided to rename everything, so when I'm finished I'll have a pretty accurately named theater. Sad? Yes... No life? Yes... Worth the effort? Absolutely!

VERY Sad.. HAHAHAHAHA, but the same could be said for ppl who play round with terra-data and VB and C# and PHP and flight sims that are 7-8 years old!

PS - I guess this is a kind of a "Kuriles Theater" announcement... At least I don't have to worry about skinning the aircraft/changing flags, etc. Thanks to Zaggy for the Russian datas and Blueprint for the SRTM terrain datas.

No worries... Just wait to you get it working and fly it with 1Km data from 30ArcSec GLOBE data, THEN get it to Bluey and get to fly it with 250m data from Bluey's SRTM...

[ccc]

some dev back in old days... for Kurile theater.

http://www.13efw.net/Japan/modules/news/

[Malc]

@ SM - no, sorry, Codec's one called DEM2Terrain - I was forgetting what it was called earlier.

@ Zag - as best as I can determine, the popultaed places are where they should be (according to Google Earth), in fact it seems bloody accurate. Names are all out though.

[Zaggy]

Malc, this is with ALL Data or just the Russian Data? Its looking like ALL Data?

[Zaggy]

Looking at your screen shot, it looks like its ALL the DATA... Which would lead me to point the finger at DEM2L... Probably something small like the names are being imported into an array and assigned to the previous or next location, instead of their location...

if it is something simple like that, wouldnt be too hard to re-parse the offending e00's to re-order the names so theyre correct in the TDF's...

Is it AIRPORTS as well? Both the AEPOINT and PPPOINT data is very similiar...

[Malc]

Yes, airports too are all to pot...

In this instance, its almost not an issue anymore cos I'm getting quite close to finishing Hokkaido now leaving only the mainland to do.

IIRC, Panama was never this bad, but that was done with the old perl scripts. I wonder if DEM2Terrain is indeed at fault?

[Zaggy]

Indeed.

If you get bored, have a look at the raw data... e00 are basically a text format, so it shouldnt be too hard to understand bits of what youre looking at... Position Data is the first major block of data (LAB Block), while Label data tends to be in the last half/third of the file (IFO Block)... You should be able to spot it...

The LAB Block will look like (in the case of AEPOINT);

Code: Select all

         1         1 1.9982750E+01 5.4941087E+01
 1.9982750E+01 5.4941087E+01 1.9982750E+01 5.4941087E+01
         2         2 2.0183059E+01 5.4885978E+01
 2.0183059E+01 5.4885978E+01 2.0183059E+01 5.4885978E+01
         3         3 2.0245757E+01 5.4953854E+01
 2.0245757E+01 5.4953854E+01 2.0245757E+01 5.4953854E+01
         4         4 2.0377546E+01 5.4781510E+01
 2.0377546E+01 5.4781510E+01 2.0377546E+01 5.4781510E+01
         5         5 2.0582700E+01 5.4914105E+01
 2.0582700E+01 5.4914105E+01 2.0582700E+01 5.4914105E+01

Now these positions SHOULD correspond to the NAMES in the IFO Block:

Code: Select all

 
 0.0000000E+00 0.0000000E+00          1        205 5BRYUSTERORT
               101990 5 13519870214
 0.0000000E+00 0.0000000E+00          2         58 5MARIENKHOF
               101990 5 21019870214
 0.0000000E+00 0.0000000E+00          3         57 5PIONERSKIY
               101990 5 9999919870214
 0.0000000E+00 0.0000000E+00          4         59 5PROVEREN
               101990 5 11119870214
 0.0000000E+00 0.0000000E+00          5         60 5KHKABROVO
               101990 5 2919870214

IF the name and positions in the e00 DONT correspond to what you see in the TDF, i would suggest that we have a problem with DEM2L...

If this does happen, look for a pattern... Some like the FIRST set of co-ords in the LAB has been named with the label from the SECOND entry in the IFO... OR perhaps the WRONG set of numbers is being read from the IFO to index the Label to the Location... Those are the two that are most likely (cos they'd be the easiest things to screw up programming!)...

Its probably best to first try this on a SMALL piece of data (like Taiwan or Switzerland or something, before checking some of the larger datasets (like Russia! hahaha)...

Of course, it could just be the Data is Screwy for some places, tho i tend to trust the data at least a little; it was what was being used to generate aeronautical charts at one stage!

But yeah, if you get bored, have a potter around... If you can come up with a pattern, i can write something to 'pre-process' the e00's, so others following do not have to endure like we have endured!

[Malc]

Okay, cheers for the explanation. I may well have a goose later on (assuming my 'kin eyes still work...)

[Malc]

Early indications are the names-places relationship is one out. Will dig deeper and confirm...

[Zaggy]

It makes sense... Tis a fairly easy programmatical error to make...

(youve a list of numbers STARTING at 1, and youre probably loading them into an array starting at 0... Its very easy to just user intCounter instead of maybe intCounter+1 or intCounter-1...)

[Malc]

Seems for sure now that the names are one out on each occasion, the objective #181 uses the objective #182's name, #1476 uses #1477's name, etc. at least in this Japan/Russia scenario.

Perhaps later I'll check out one or two other small sets, but all in all I reckon there may well be a problem in Codec's DEM2Terrain program version 1.9

Progress update - Blue = yet to be renamed Green = accurately renamed

[Sherlock]

I've been doing a middle east theater and the major cities appear to be correctlly named (but I haven't checked each and every one to be sure). How could the DEM2Terrain program be the cause of the "one off" error you are experiencing Malc if the data is correct in other areas of the world? It would seem to me to be a data error for that area (Japan) you are doing....?

I will check a little deeper and see if any names are off in my area and report back here.

[Malc]

How could the DEM2Terrain program be the cause of the "one off" error you are experiencing Malc if the data is correct in other areas of the world? It would seem to me to be a data error for that area (Japan) you are doing....?

Not sure exactly mate, but thinking about it more, I am inclined to suspect this is a one time balls-up only. I've done Indian/Pakistani area before (Kashmir) and all was well with that right enough. I thought it was Zag's Russia data at first, but then it was Japan as well, so that clarified the Russia stuff was fine.

I will check a little deeper and see if any names are off in my area and report back here.

Thanks - if nothing else it will confirm this event is indeed a "one off"...!

[Zaggy]

Also remember, the places wont be out by MUCH... The points are numbered somehow so the next number is fairly close to the last number... BUT this is interesting...

SO, SOME area's work and others may not... Before i start coding a small fix, we should confirm this... I wonder if it has to do with something in DEM2L like - or + longitude?

Anyway, malc, can you whip me up a short doc on the problem, and make it NICE and clear if its the ARC or the LAB scetors that are +1 or whatever; maybe even a few rows of example data.

Once we have a confirmation, and a documented problem, I can code something up to help future suckers, err, terrain builders... Like a 'pre-process' utility for point e00's, so we re-order the data, so DEM2L's output is correct...

[Sherlock]

Ok, I checked the major cities (where the poly areas of orange show up in TV) and all the cities are properly named and situated on those orange areas of the map in TacEdit. The coordinates on the theater I checked them in are:

Centered on: Lat 32.25 Long 49.1
NW: Lat 36.8531 Long 43.3473
NE: Lat 36.8531 Long 54.8527
SW: Lat 27.6469 Long 43.9036
SE: Lat 27.6469 Long 54.2964

Edit: Oh, and airports are all spot on also.

[Zaggy]

Cool... This is becoming stranger and stranger, isnt it!

Other factors could be:
- number of 'countries' worth of data
- longitude/latitude

pretty much everything else i can think of really couldnt have much of a bering on the outcome (DEM Data, Theater size, etc)

[Malc]

Indeed... in trying to come up with a small write-up for you, I am struggling to discover the true relationship of the error. For the cities and airbases, it was one out, but now I'm looking deeper at the villages, the names assigned to the objectives appear to be random! Its doing my f*****g head in!

I'm only using Japan and Russia East, so there's not lot of opportunity for it to go tits-up there, and when dicking around in the past with Scotland data, that is at 57 degrees North approximately, which is abpout 10 more than this theater.

I'm gonna try one thing - I'm gonna remake the theater using only the Russia East data (not bother with Japan) and see what happens... I'll let you know.

[Zaggy]

Cool man... Im just curious as its such a 'weird' thing. Seems pretty rough having to rename all the point data because something bizarre has gone on... But yeah, if you find anything, just let us know!

[Malc]

Well, after much feckin around and trying various things, I can only assume I screwed up somewhere...

Russia on its own is perfect.
Japan on its own is perfect.

I have a feeling, and after-thought... Before I imported the objectives.csv into tacEdit, I ran it through Excel to make all the names proper (cos am a fussy twat see...) and I am now wondering if I managed to copy the data one row out at some point. I am now thinking more and more this is what has happened.

So, with that... move along now, nothing more to see here. :embarassed:

[Sherlock]

Well, I'm glad we cleared that up....!

[Zaggy]

Good stuff... all is NOT lost!

[Snake Man]

I ran it through Excel to make all the names proper

I use EditPadPro (good text editor), it has feature called Initial Caps and it works great for this kind of task. I havent done this to all theaters objectives yet, but in the next cycle I'll make sure all theaters will be nicely setup for upper/lowercase characters.