Spectrum Spatial (SSA/LIM)

 View Only
  • 1.  Unsupported fonts not supported in SSA

    Posted 02-05-2019 19:35
    Hi All

    I'm using MapInfo Professional V17 (64 bit) Release Build 71 and SSA V12.2.

    I'm uploading a ManInfo Native points table of various types of "pits" but it is being rejected in Map Unloader with a message saying:

    Labels error with points in Pit layer
    I have tried several things and have changed all the points to have the same symbol but with different colours (also went down the thematic layer avenue) to avail. 
    I have referred to the Map UpLoader manual and on page 13 it refers to "unsupported label and style settings" and note that under "unsupported fonts" page 14 it refers to using font Arial Unicode Ms for labels to appear correctly in SSA.

    Is there an alternative to this font as the MI version 17 doesn't have this font available?

    Also has anyone got any suggestions that I might be doing something wrong?  

    regards


    ------------------------------
    Jenny Levy
    GIS Co-Ordinator
    Benalla Rural City Council
    Benalla
    ------------------------------


  • 2.  RE: Unsupported fonts not supported in SSA

    Posted 02-06-2019 04:11
    Edited by Monica Di Martino 02-06-2019 04:12
    Hi Jenny,

    May you check, and tell us, the Label Expression you're using for labeling  in MapInfo Pro?

    it seems the problem could be the Expression as it's not possible to upload a map having expression in the labeling. You might use only the  column name so Pit_Type.

    ------------------------------
    Monica Di Martino
    Knowledge Community Shared Account
    ------------------------------



  • 3.  RE: Unsupported fonts not supported in SSA

    Posted 02-06-2019 10:29
    ​Jenny,

    The error message is saying that the label expression, which is just the column 'Pit_Type', could not be found as a column in the table that was found.
    I believe that error message to be accurate so what would do is to check the Spatial manager and see if the Named Table is connecting to a version of the table where that column does not exist.
    Do you know how to do this in Spatial Manager? Do you think there could be multiple copies of this table? That would explain this error.

    ------------------------------
    Eric Blasenheim
    Spectrum Spatial Technical Product Manager
    Troy, NY
    ------------------------------



  • 4.  RE: Unsupported fonts not supported in SSA

    Posted 02-06-2019 16:00
    ​Hi Jenny,

    I have had a similar error message and discovered the issue was actually with the table structure.
    Even if you delete all reference to the table in Spatial Manager it seems to remember it elsewhere which will mess things up if the slightest modification has been performed on your table.
    There are two approaches you may like to try:
    1. Remove all reference to your existing "Pits" table, rename it and try uploading again.
    2. Ticking the "Volatile" checkbox in Spatial Manager if you wish to retain the original name.
    I hope this helps.

    ------------------------------
    David Murphy
    GIS Officer
    Swan Hill Rural City Council
    Swan Hill
    ------------------------------



  • 5.  RE: Unsupported fonts not supported in SSA

    Posted 02-06-2019 21:25
    Hi Jenny,

    David's suggestion rang a bell.  I have checked my notes to find the following:

    o   Upload error: invalid expression.  Identifier = 'EZI_Num_Address'
    o   Cause: the table definition within Spatial Manager is not overwritten.  Therefore, the new field cannot be found.
    o   Solution: Delete these tables (and associated layers) in Spatial Manager, re-upload.

    ------------------------------
    James Nolet
    Dooley Mitchell & Morrison Pty Ltd
    Mentone East
    ------------------------------



  • 6.  RE: Unsupported fonts not supported in SSA

    Posted 02-07-2019 00:26
    ​A big thank you to everyone that responded to my SSA query.

    Everything has now loaded correctly after I took your advice David..... made a new copy of the Table with a new name and made sure that even the folder in Spatial Manager had a different name.   Worked first time! 

    It is interesting because I had removed the folder/links in Spatial Manager several times but it appears that when uploading it was not overwriting it as you mentioned James.

    kind regards

    ------------------------------
    Jenny Levy
    GIS Co-Ordinator
    Benalla Rural City Council
    Benalla
    ------------------------------



  • 7.  RE: Unsupported fonts not supported in SSA

    Posted 02-07-2019 10:51

    ​Jenny,
    I am glad that your situation is working but as Technical Product Manager, I need to ensure that the information on this community is correct and does not imply unnecessary actions by our customers. Clearly we need to make this more understandable so that this would not occur. 

    First of all, titles matter and this thread has absolutely nothing to do with fonts. I hope that future visitors would not find that and think it did.  Maybe we can change it to "Handling volatility of Named Tables"
    Secondly, when a error about a column not existing appears, it is either because the named table is pointing to a different version of the table (which was my first idea) or because the table changed,  then named table was set to non-volatile which to the server means you have declared it won't change.

    David Murphy was basically correct when he said "Even if you delete all reference to the table in Spatial Manager it seems to remember it elsewhere which will mess things up if the slightest modification has been performed on your table."  This is true if the Named table is non-volatile which means it will not change.
    Technically what this means that IF the named table is marked as non-volatile, (volatile false) then the server code caches all the information about the TAB file (or database table) in memory for performance reasons; note not on the named table, the actual data source. See more below.

    The table is supposedly not changing so that is what we do and this really helps with performance for map tiling/rendering and heavy querying. We want folks to keep tables non-volatile whenever possible. 

    The key then is how to get Spatial to forget about this information and read anew from the table. This could be a column change, even just its name, a change to the spatial data that has caused an index change and probably others. So if the data has changed, the data is volatile.
    As David mentioned, toggling the named table to volatile (and back) should do the trick. I will post back if I can find cases where this is not true.
    In version 18.2, there is a restart button under settings. This will clear all caches as the spatial piece is starting over.  If you are doing bulk changes to the data, it is recommended to use this after applying the data . This should happen when the server is not in heavy use. 
    This way you can keep the data non-volatile for performance and only flush our cache when necessary.  Restarting just spatial is not time consuming and much faster than a complete Spectrum restart.
    Currently the map uploader always sets the tables to non-volatile. This was in response to many performance complaints. I now believe that we have to expose this via the uploader so that people can choose.  However, I think that there are ways to maintain performance for data that is only changing occasionally.

    Summing up you should never have to copy the data to a new name or folder in the repository to make any of this work.
    Jenny, you said :
    "It is interesting because I had removed the folder/links in Spatial Manager several times but it appears that when uploading it was not overwriting it as you mentioned James"

    The comment about the internal cache on the table and not the named table, is why you can delete the named table and still have this issue as the code remembers the data source. Hopefully you have one named table for that data. That is the idea.  If you delete the named table and redo the upload which recreates it, the internal code still has the same old cache. So again, got to get rid of that cache. 
    I have some thoughts of things we could change in the uploader but I really don't want to start that discussion on a thread about
    "fonts". I will start a new and love to hear your thoughts.



    ------------------------------
    Eric Blasenheim
    Spectrum Spatial Technical Product Manager
    Troy, NY
    ------------------------------