Spectrum Spatial (SSA/LIM)

Welcome to the Spectrum Spatial (SSA/LIM) community - start a discussion in the discussion tab or join in a conversation.

SSA Documentation  LIM Documentation  SSA Ideas  LIM Ideas

Discussions

Members

Resources

Events

 View Only
  • 1.  What is better to use for map layers within SSA: SQL Server spatial tables or MapInfo tables?

    Posted 07-06-2018 07:00

    Within other GIS viewers it has been common for map display speed to slow down significantly if too many SQL Server spatial layers are used. The method employed by myself and others in the past is to ensure all layers are native (or non-dynamic) MapInfo tables. I understand that other factors can affect the speed (such as whether you are linking to SQL Server views rather than tables), but I was wondering if this is something to be considered when setting up SSA. Should I consider exporting the SQL Server tables as MapInfo tables if I encounter map display speed issues?

    I'm interested in finding out what others have experienced and what P/B advise.

    Thanks.



  • 2.  RE: What is better to use for map layers within SSA: SQL Server spatial tables or MapInfo tables?

    Posted 07-06-2018 17:28

    ?I apologize in advance for the dreaded introduction: "It depends" but it does.

    Here's things to consider.

    MapInfo Native Tab files require good disk access. One of the reasons I am surprised that a number of SSA customers access their files on a UNC path to a different box is that this can never be optimal in terms of disk access and disk cache. 

    I do understand the problem they want to solve (single source) but I do wonder if they have negated the benefit of Native by doing it this way. Obviously, the speed of your network between Spectrum (not Analyst) and the file server can vary tremendously. VMs often have a shared physical disk so performance can vary based on use of other VMs.  But by far the biggest factor is disk access including cache. 

    This is also one of the reasons why Spectrum Spatial is pretty cheap on memory.

    Other reasons why Native TAB is a good choice:

    1) Labelling of polygons is faster as the file has a built in label point (centroid).

    2) Styles embedded in the table. 

    3) Internal knowledge of the structure allows us to do some smart things. The built in spatial index is always there. FindNearest is one of those. 

    4) Fetching data by key is fast.

    Where Native is not always best is with non-spatial queries, particularly joins or more complicated ones. All that is our code and essentially done in memory.

    With a database we have the logic in place to try and pass the query down to the database. Only when we can't figure out how to do this in the database do we have to process it ourselves. So a well tuned database with a good network connection can be great, can scale and perform without much help from us.  Plus it has that single source built in.

    Note managing data is still a job. 

    But basic rendering and mapping is rarely faster in a database.  Like I said, with smart tuning, it could be.

    In the end, understand what you are trying to do with your spatial assets and understand what your IT limits are.  Sometimes the GIS or LI people in an organization have very little pull to get the resources they need, even if not very expensive. I had to sit with a customer's IT for many hours using a few different tools to prove that their disk access was really bad including a tool that did not use our code at all.  Once they reluctantly agreed, they moved all their data. 

    Another wanted to move to SQL Server, all seemed ok but their connection speed between Spectrum VMs and the database was terrible. 

     

     

     



  • 3.  RE: What is better to use for map layers within SSA: SQL Server spatial tables or MapInfo tables?

    Posted 07-08-2018 22:11

    Hi James,

     

    Good question. In previous GIS software systems we have run into speed/performance issues when pointing to sql tables/views and reverted to using flat /tab files. We feared we may have similar issues when deploying our internal SSA system so we have also used flat .tab files for our data source. We have been running V12.1 for some time now for our main internal mapping system and the speed for opening/viewing/querying is absolutely blistering fast! Therefore at this stage we have no intention of pointing SSA to our sql db, even knowing this would be best practice. While our single source of truth and data warehouse is in sql which is where all the magic happens with data creation and manipulation, we then have flat tab files refreshed nightly for SSA to point to (these ARE NOT linked!) and we have no intentions of changing this at this stage.. Because of the fast speed that are users are now accustomed to with V12.1 I fear from our recent experience of upgrading (then rolling back 12.1) to V12.2 that we will go backwards, so I am hoping the 12.2.1 is also a step forward in all respects..

    Tony Jordan



  • 4.  RE: What is better to use for map layers within SSA: SQL Server spatial tables or MapInfo tables?

    Posted 07-09-2018 00:43

    Thanks Eric and Tony. I knew the answer would depend on a lot of factors but that is great information to go on with. I like the idea of linking directly to the db, but am glad to know that it might be possible to handle speed issues by falling back on Native-MI if need be (via an overnight process as Tony suggests - most likely using ogr2ogr scripts). And I'll definitely avoid network UNCs if I have any input in this aspect of the setup at client sites.

    I appreciate the advice.