Global Mapper v25.0

"Or" in Query doesn't work

Syrett
Syrett Global Mapper UserTrusted User
I'm working with the Attribute Editor to select features. In the Query Builder, I assumed that "or" would enable me to select objects of different values within the same Attribute. For example, in a search for features within OSM areas, I created a query like this:  %GM_LAYER%  =  'leisure - park'   or   'leisure - pitch'  . But all I get are the parks. If I reverse the order of the Values, all I get are the objects tagged as "leisure - pitch". My understanding is that all features with these values should be returned, as described here: https://www.bluemarblegeo.com/knowledgebase/global-mapper-19-1-v2/Search_Vector_data.htm


Answers

  • Syrett
    Syrett Global Mapper User Trusted User
    Got my answer - the  Attribute also needs to be repeated, not just the Values. Looks like Queries don't follow the economies that common speech does! :)

  • bmg_bob
    bmg_bob Global Mapper Programmer
    Syrett said:
    Got my answer - the  Attribute also needs to be repeated, not just the Values. Looks like Queries don't follow the economies that common speech does! :)

    Hello,

    This is correct.  The query you need is:
    %GM_LAYER% = 'leisure - park' or %GM_LAYER% = 'leisure - pitch'
    Cheers,
    Bob
  • JeffH@BMG
    JeffH@BMG Global Mapper Developer Trusted User
    Hi Syrett and Bob,

    I think that parsing the original query to get the intended meaning might be a little tricky. That kind of query is probably going to pop up again. Treating a literal string or a number as a Boolean value doesn't make a lot of sense. Have to think about that. maybe that would be worthy of a warning.

    I'm wondering whether a new syntax like
    %GM_LAYER% in { 'leisure - park', 'leisure - pitch' }
    would would be clearer (or at least shorter). Under the hood it would just translate to something akin to the query that Bob suggested. 'in' would be a new operator, and the stuff between the '{' and '}' would be a comma-delimited list of text or numbers. It still wouldn't preclude the problem of a user intuitively trying something like the original query, and getting a mysterious result.

    Best,

    ~Jeff
  • Mykle
    Mykle Global Mapper User Trusted User
    Jeff,
    The overall issues should be: 1) syntax that conforms to similar statements used by other systems (like SQL) as well as within the overall structures defined within the Attribute Editor, and 2) syntax that is well-documented within the Global Mapper Help system. 

    As the one who referred to the Help system to suggest a change of syntax to Syrett, I found the Help to be clear.  That's hard to beat!  Well, having Bob for backup is even better. 

    I don't have that much experience with the Attribute Editor, and have SOME experience with MySQL, so I don't have any specific recommendations other than my statement above. 
    Cheers,
    Mykle
  • JeffH@BMG
    JeffH@BMG Global Mapper Developer Trusted User
    edited March 2018
    Howdy Mykle,

    I implemented the original attribute query language and system, used in the Attribute Calculator (so it's kind of my baby), before Bob did some great work integrating it into the Search Vector Data dialog, and improving it. I based the language on Excel formulas, and it got augmented with some SQL-like additions (e.g., 'LIKE') along the way. Both of those sources are fair game in my book, but we're not limited to those.

    But in this case SQL does have a similar construct (which I wasn't previously aware of), an 'IN' operator that looks like this:
    %GM_LAYER% IN ( 'leisure - park', 'leisure - pitch' )
    This uses () instead of {} as list delimiters, but it's otherwise pretty much the same thing. I'm pretty certain that we could probably document this pretty well in Help.

    The other question, of course, is what should we do with the (potentially) troublesome %Attr% = "A" or "B" type constructs? That's a bit of a different concern: trying to make sure that users are getting what they expect, or are at least warned that what they expect might not be what they get.

    Anyways, thanks for the input. Happy weekend!

    ~Jeff