ngageoint / hootenanny

Hootenanny conflates multiple maps into a single seamless map.
GNU General Public License v3.0
353 stars 74 forks source link

Dealing with <Null> in translation scripts #95

Closed sisskind closed 8 years ago

sisskind commented 8 years ago

We are seeing FGDB attribute tables with in many cells. In using an IF statement in JavaScript to determine if a cell is populated or not the word null has special meaning in JavaScript. It is not a simple check for the string "". There are a number of on-line discussions about what null is including it is an object, a JavaScript bug, and at the very least a reserved word of some kind. So have any of you had to work with the value when reading from a FGDB attribute table? Any advice is appreciated.

mattjdnv commented 8 years ago
Short Answer: Inside the translation scripts, I haven't had to deal with NULL values. Long Answer: If you are dealing with TDS FGDB/Shapefiles with Thematic Groups, you will see a lot of NULL values. Using the TransportationGroundCrv as an example, this Thematic Group includes 47 different FCODES (AQ151,AQ040,AQ056,AQ045,AQ050,AQ055 etc) When you add all of the attributes for these FCODES together, you end up with 115 attributes (114 + FCODE). Since each FCODE doesn't need all of these attributes, ESRI Shapefiles/FGDB have the attributes that are NOT valid for an FCODE filled with NULL values. E.g. AP030 (Road) does not have BOT (Bridge Opening Type), RWC (Railway Class) etc so these get filled with NULL values. Inside Hoot, the C++ code strips out the NULL values before they are passed to the translator: OgrReader.cpp, Line 568: // Ticket 5833: make sure tag is only added if value is non-null if ( value.length() == 0 ) { /* LOG_DEBUG("Skipping tag w/ key=" << fieldDefn->GetFieldDefn(i)->GetNameRef() << " since the value field is empty"); */ continue; } Does this help? Matt
charlieburgwardt commented 8 years ago

To handle the from ESRI FGDB attributes I simply changed the if statement to if(attrs['Attribute_Name']) from if(attrs['Attribute_Name]!=''). From what I see on-line JavaScript will return false with this statement for empty strings (""), null, undefined, false and the numbers 0 and NaN. The only value here that I was concerned about was the number 0 so I tested to see what would happen if I assigned a numeric zero to an attribute. JavaScript did not return false apparently treating it as text. I can't say this will work with all numeric attributes but it seems ok for now.

Thanks for the info on OgrReader.cpp, Line 568 (Ticket 5833). Since the text string that is being read has Null with < > around it as in it may not be stripping out the null. However when this string is interpreted by the JavaScript translation it is being treated as though it is the reserved JavaScript value "null".

The bottom line may be that since the is a common, possibly default, value in ESRI attributes we may want to have a special test for it. In the meantime I think the if statement I described above is a more robust solution than what is currently presented in the User Guide, page 15.

bwitham commented 8 years ago

This issue appears closed. If not, please reopen it.