Welcome, Guest
Username: Password: Remember me

TOPIC: Control "draw order" of multiple at5-files

Control "draw order" of multiple at5-files 7 years 4 months ago #10992

  • Team Krokodille
  • Team Krokodille's Avatar
  • Offline
Thanks for the help guys, I think I might have figured out what's causing the issue. I'm usin FME to create custom attributes/categories and it seems that when writing to shape the attributes are encoded as "windows-1252" while the corresponding attributes that are created when exported directly from Reefmaster are encoded as "string". This is the case for amongst L_LIMIT, U_LIMIT, LAYER and COLOR (and some more). When forcing FME to format these attributes as STRING the maps are at least read correctly on my Elite emulator (they would not read at all on the emulator before I made this change even though they were read on my NSS unit). The Elite emulator however does not seem to support displaying multiple maps simultaneously so I will have to wait to test and confirm that the issue is solved until I get back home and test on my NSS unit. (On easter holidays now).
The administrator has disabled public write access.

Control "draw order" of multiple at5-files 7 years 4 months ago #10993

  • gpiverson
  • gpiverson's Avatar
  • Offline
All 4 of those attributes (L_LIMIT, U_LIMIT, LAYER, COLOR) are numeric fields.

If the LAYER is encoded as a string, it would default to 100.
The administrator has disabled public write access.

Control "draw order" of multiple at5-files 7 years 4 months ago #10994

  • Team Krokodille
  • Team Krokodille's Avatar
  • Offline
Yes, I cannot explain it, maybe its just how FME interprets the shapefile, but when exported directly from Reefmaster those attributes are shown as string format. So when I changed to string format on my map attributes also things started working. I do not get any errors while creating the at5 file in IMC. When creating the at5 file before, IMC created all three maps, large, medium and small, even though I had U_LIMIT set to 19. After changing attribute format to string only the large file is created, indicating that the attributes are now read correctly...

Last Edit: 7 years 4 months ago by Team Krokodille.
The administrator has disabled public write access.

Control "draw order" of multiple at5-files 7 years 4 months ago #10996

  • fjordfisher
  • fjordfisher's Avatar
  • Offline
I could be the same problem, as in ArcGIS (long time before).

If i edit a RM-shape in ArcGIS, the attribute table will be damaged. Look to the attachment before and after editing (i changed MODE "T" zu "N").
In this case only can help: Load the file in QGIS, save with new name and now i can the new shape file use ArcGIS without Problems. It's an problem with the field lenght definition, if i remember correct.

FME could be have the same problem?




Last Edit: 7 years 4 months ago by fjordfisher.
The administrator has disabled public write access.

Control "draw order" of multiple at5-files 7 years 4 months ago #10997

  • Team Krokodille
  • Team Krokodille's Avatar
  • Offline
That just might be Fjordfisher, but I'm feeling positive I've created a workaround by manually encoding the previously mentioned attirbutes to string. They seem to be read correctly by IMC, but I will know for sure when I get back home and test on my Simrad NSS. Will post an update after that. :)
The administrator has disabled public write access.

Control "draw order" of multiple at5-files 7 years 4 months ago #10999

  • gpiverson
  • gpiverson's Avatar
  • Offline
Sounds reasonable that FME is reporting them as strings. They distinguish actual character strings by their encoding.

Probably some hack that FME uses for a consistent user interface across multiple data formats. DBF numbers are strings rather than being binary encoded but it would be very confusing to users to refer to them that way.

I don't think it's the same as the ArcGIS bug.
Last Edit: 7 years 4 months ago by gpiverson.
The administrator has disabled public write access.

Control "draw order" of multiple at5-files 7 years 4 months ago #11000

  • gpiverson
  • gpiverson's Avatar
  • Offline
A quick search found this response - knowledge.safe.com/questions/50441/shape...fields-as-strin.html
To answer this question, I need to explain some FME history. In the very beginning, our goal was to completely hide the internal representation of data from end users. We would look after any conversions that were ever going to be needed and do them automatically. And our original FME implementation was that we would handle any attribute we read as a string internally. This provided a very easy and consistent way of working. And all the early formats of FME were written accordingly -- they all created internal FME representations as strings. Shape is one of those, and this makes good sense because actually all attribute data in a shape file is actually stored as a string ultimately.

With time, we expanded the power of FME and for efficiency sake we added the ability to store attributes in the native type that we read them. So if a format could give us a number as a float or double or int, we'd just store that. And by so doing, avoid converting things into strings if we didn't need to.

For the most part we didn't go back and retrofit existing format code, because FME will do whatever conversions are necessary anyway and all this is hidden from the user. (Except at some point the python call was made available which is what you have stumbled upon).
Note that we have no intention of updating our shape reader. Why? Well, in the case of Shape, the attribute data is actually all stored in the DBF file as...you guessed it...strings. Even if the DBF says it is a number. And so we don't want to take on the expense of converting those strings into numbers to pass through FME because there is an excellent chance we may never need to during the whole translation. If we go shape->shape for example, it is just going to get written out as a string ultimately anyway.

So Takashi's technique of inspecting/using the actual schema feature is truly the only way to reliably know what the original format intended the attribute's type to be. The storage format in FME is not guaranteed to be the same. I apologize for the confusion the python call may have caused, and hope we can find a way to get you the results you need without undo trouble.
The administrator has disabled public write access.

Control "draw order" of multiple at5-files 7 years 4 months ago #11017

  • Team Krokodille
  • Team Krokodille's Avatar
  • Offline
Hi guys.

A late update from me. Formatting the attributes as "string" as earlier explained solved the issue and the layers in all mye separate maps are now layered correctly on top of the depth maps as expected.

Now, my problem is to display them as transparent. First i discovered that the attribute "IMG_RENDER" has 11 characters witch is in fact illegal according to the shape format specifications. Shape field names can maximum have 10 characters, and since FME follows these rules strictly any files made by FME will have the following characters after 10 removed som the attribute will be renamed to "IMG_RENDE" and thus not recognized by IMC. The solution was to edit the attribute with the IMC in attribute mode (wich allows for field names longer than 10 characters).
However, I'm stil not getting the transparency displayet. I have "IMG_RENDER" at "153" now wich should correspond to about 60% transparency in Reefmaster. I'm guessing it has to do with the xml-file but have not figured it out.

What exact information lies in the xml-file and how to read it? As I understand there can only be one xml file and it has to be in the SD-cards root folder. How to fix this when you have multiple at5-files wich all includ transparent layers?
The administrator has disabled public write access.

Control "draw order" of multiple at5-files 7 years 4 months ago #11018

  • gpiverson
  • gpiverson's Avatar
  • Offline
"IMG_RENDER" only has 10 characters. All 11 character fields will read as 10 character fields (last character truncated) in the IMC.

While the 10 character limit is technically a limitation of the format, it's only a limitation if all string values must be null terminated. Since every string is fixed size (field headers are fixed at 11 bytes), that's a silly requirement which is why the IMC doesn't follow that part of the standard. 11 character fields are used because I didn't learn about that restriction until after I started coding the exchange format. The truncation to 10 character fields made it work with other GIS software packages.

AT5 XML files, generally speaking, shouldn't be combined. You should export as At5 Major Version 13+.
Last Edit: 7 years 4 months ago by gpiverson.
The administrator has disabled public write access.

Control "draw order" of multiple at5-files 7 years 4 months ago #11019

  • Team Krokodille
  • Team Krokodille's Avatar
  • Offline
Hi gpiverson, yes that was a bit embarrasing for me. What I meant was thet "BDR_PATTERN" is 11 characters. But anyway, yes I agree and understand what you are writing. This is no big deal for me. I discovered it because I use FME to write my thematic map files as I need to use costom categories for the layers. I could'nt figure out why my borders were not dashed. Then I finally understood that it was because FME had written the wrong attribute name "BDR_PATTER". No big deal, I just use IMC in attribute mode to add the last character in the field name now.
I want to keep my thematic maps separated and not merge into one map because they contain a lot of data and I want the users so be able to use only parts of the data, not having to load everything into their units. If I keep evere at5 and xml in separate subfolder, will the unit read all xml files? I've tried this but it still did not seem to work....
The administrator has disabled public write access.

Control "draw order" of multiple at5-files 7 years 4 months ago #11020

  • gpiverson
  • gpiverson's Avatar
  • Offline
The chart plotter will not merge the XML files together.
The administrator has disabled public write access.

Control "draw order" of multiple at5-files 7 years 4 months ago #11021

  • Team Krokodille
  • Team Krokodille's Avatar
  • Offline
Hi, sorry for being unclear again. What I meant was: If I have 5 different folders on my SD-card, each containing an at5 file of a map with transparent layers and a corresponding at5.xml file specifying the transparency of the layers. Will my unit read all 5 xml files thus displaying all 5 maps correctly?
The administrator has disabled public write access.
SCROLL TO TOP