Search and Edit Failure in GM 13.1

Roger EdrinnRoger Edrinn Global Mapper UserPosts: 721Trusted User
edited March 2012 in Bug Report
So I'm trying to edit some poorly created names that will not shield, these county GIS guys can name every road different. Do a search on a string, find a highway, select, Edit select, type in a GM recognizable name, up pops the Do you want to iconized these dialog, click Yes, nothing happens.

I've placed the gmw file and shapefile in your FTP folder to test: RioAribaRoadTest.gmw tl_2009_35039_edges.zip
Search Feature Name "State*", that will bring up State Hwy 110, change to SR110, nothing will happen.

Seems a bug to me.

Comments

  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited March 2012
    There has been a change in v13.1 to how the labels work and I maybe didn't have the defaults set as how makes the most sense. Now when you setup attribute-based labeling that no longer overwrites the set label for the feature. You are just specifying what to display and the label is built on the fly. This allows you to use attribute-based labeling and change the attribute value and the display label will automatically update to reflect that. You can also setup custom labeling based on attributes and any custom text. Finally you can go back to the original label since it is no longer overwritten.

    All of this is controlled on the Options dialog for the layer where you setup the attribute-based labeling. There is a checkbox there to allow you to keep the original label for a feature as the display label rather than using the attribute-based label, thus allowing you to directly edit the display label even when an attribute-based label is in use. This checkbox used to be a direct prompt when you changed the labeling and I had defaulted it to unchecked, which mean the original or directly edited label would not be used if you setup any type of attribute-based or custom labeling. This was confusing as you could edit the label in the Digitizer Tool but the edits didn't show up on the map since you had attribute-based labeling setup and that was overriding your edited label without that option checked. I have now defaulted that option to checked so by default the attribute-based labels aren't used if there is already an explicit label for the feature. This should behave more how you expect.

    I have placed a new build at http://www.globalmapper.com/global_mapper13.zip with the latest changes for you to try. Simply download that file and extract the contents into your existing v13.xx installation folder to give it a try. If you are using the 64-bit v13 version there is a new build at http://www.globalmapper.com/global_mapper13_64bit.zip .

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
  • Roger EdrinnRoger Edrinn Global Mapper User Posts: 721Trusted User
    edited March 2012
    That was long winded.

    How about an example based on my post and files. Should I be doing something different.

    Thanks
  • Roger EdrinnRoger Edrinn Global Mapper User Posts: 721Trusted User
    edited March 2012
    Doing a little experimenting. Since the source of the Feature Name was a field called Rte No, I did a change on that field and it appeared to automatically correct the Feature Name and create the shields. Was that what you were saying?

    What is the logic for the change? Seems I'm destroying base field information.
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited March 2012
    That is how the attribute-based labeling now works. So if you have labels based an attribute value and you change that attribute value, it necessarily follows that the label based on that attribute also changes. That way you don't have to make the change multiple times. The original label is still there and you can get back to it if you disable attribute-based labeling, or actually it will be displayed if you check the option to override attribute-based labels with the specific label for the feature.

    The real reason these changes were done was to allow the new option for labeling which is a completely custom label made up of other pieces with any custom text, including the original feature label as part of that. This allows you to label things like area features with the original label of the area as well as perhaps some measurement attributes like enclosed area and other attributes, each on their own line, all without destroying the original label so you can change the custom label freely and not lose anything. Also the display label will update with the new measurement values automatically as you edit the feature shape.

    However as I've thought about this I'm thinking there may be a few more minor tweaks to more easily allow attribute-based labeling in conjunction with direct editing of labels, although I think for what you are doing what you want now is to edit the attribute value you are basing your label on if you are using attribute-based labeling, then that will update the display label as well.

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited March 2012
    I decided to add one more change to this so that you can have all of the behavior that you used to. Now if you setup attribute-based labeling and you have the option checked to use the default label if present, you will be prompted to overwrite the default label with the new attribute-based label. If you check yes then all labels will be updated with the new attribute-based label and you can then directly edit the labels with the Digitizer Tool, but then the dynamic updating when the attribute value changes won't work. This is how things used to be. If you select No then any default label will be kept and will show if you have the option checked to keep default labels. If the feature didn't have an original or edited label or you uncheck the option to keep default labels, then you will get the dynamically updating attribute-based label.

    I have placed a new build at http://www.globalmapper.com/global_mapper13.zip with the latest changes for you to try. Simply download that file and extract the contents into your existing v13.xx installation folder to give it a try. If you are using the 64-bit v13 version there is a new build at http://www.globalmapper.com/global_mapper13_64bit.zip .

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
  • Roger EdrinnRoger Edrinn Global Mapper User Posts: 721Trusted User
    edited March 2012
    I don't get it. I loaded the latest build. I used the options switch in Overlay CC to set the Feature Name to Rte No. Some of those numbers have an alpha prefix which I want removed. Use Search and Replace, said it replaced 50 items, but nothing changed. The only way I can change the Feature Name is to change the Rte No attribute, which destroys root attribute information.

    You say it works like before but it clearly doesn't. I totally fail to see the virtue in these 13.1 changes. Do I have to go back to v12?
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited March 2012
    Do you have the option checked on the Options dialog for the layer to 'Keep Original/Edited Label if Non-Empty'? If you don't have that checked and you are using attribute-based labels then your search-and-replace wouldn't show up because your labels are coming from the attribute and not from any custom label for the attribute, so unless you change the attribute value itself the value won't change. If you however have that option checked then any custom label will be used.

    The new changes are because a lot of users wanted the labels based on attributes to dynamically update when the attribute value itself changed, that way they don't have to duplicate their changes or keep re-specifying that the label is based on the attribute values so the label is updated. The old way also required more memory and disk space when saving the workspace even though the data for the label already existed in the attribute values. Some users also wanted more advanced custom labeling capabilities which you can now do (and may eventually include HTML support for even more advanced styling within a single label).

    However this is different than how you have been doing things, which is why I added the new option to actually update the custom label stored for a feature when you assign an attribute-based label (this is basically what always used to happen) if you have the option checked to keep the original/edited label. If you make sure to check that then you should basically have the old behavior that you are used to. When you need the dynamic changes possible with the new behavior you can always uncheck that option, but in the latest builds it should be on by default.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
  • Roger EdrinnRoger Edrinn Global Mapper User Posts: 721Trusted User
    edited March 2012
    Do you have the option checked on the Options dialog for the layer to 'Keep Original/Edited Label if Non-Empty'? If you don't have that checked and you are using attribute-based labels then your search-and-replace wouldn't show up because your labels are coming from the attribute and not from any custom label for the attribute, so unless you change the attribute value itself the value won't change. If you however have that option checked then any custom label will be used.
    No, I did not. Consider having, if possible, that checked by default. Otherwise users unaware of this major change will individually be bugging you as to why GM has gone to hell. People whowant/need the feature will be glad to uncheck.
    The new changes are because a lot of users wanted the labels based on attributes to dynamically update when the attribute value itself changed, that way they don't have to duplicate their changes or keep re-specifying that the label is based on the attribute values so the label is updated. The old way also required more memory and disk space when saving the workspace even though the data for the label already existed in the attribute values. Some users also wanted more advanced custom labeling capabilities which you can now do (and may eventually include HTML support for even more advanced styling within a single label).

    However this is different than how you have been doing things, which is why I added the new option to actually update the custom label stored for a feature when you assign an attribute-based label (this is basically what always used to happen) if you have the option checked to keep the original/edited label. If you make sure to check that then you should basically have the old behavior that you are used to. When you need the dynamic changes possible with the new behavior you can always uncheck that option, but in the latest builds it should be on by default.
    Thanks for explaining. Perhaps someday this will be a "FEATURE" for me too. Not today.
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited March 2012
    One of the changes that I made in the last couple of days in response to your feedback was to check that by default, but if you had saved a workspace with the v13.1 release it would be explicitly set in the workspace so the new default wouldn't matter. We are about to about the installers for v13.1 with all of the changes and bug fixes, so other users should get it checked by default and hopefully avoid confusion. Although admittedly there is more potential for confusion with the new way that things work, I suppose that comes with the additional flexibility and needing to server different sets of users with different expectations of how they want the labeling to work.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
  • Roger EdrinnRoger Edrinn Global Mapper User Posts: 721Trusted User
    edited March 2012
    One of the changes that I made in the last couple of days in response to your feedback was to check that by default, but if you had saved a workspace with the v13.1 release it would be explicitly set in the workspace so the new default wouldn't matter. We are about to about the installers for v13.1 with all of the changes and bug fixes, so other users should get it checked by default and hopefully avoid confusion. Although admittedly there is more potential for confusion with the new way that things work, I suppose that comes with the additional flexibility and needing to server different sets of users with different expectations of how they want the labeling to work.

    While I appreciate your willingness to incorporate new features into GM at user request, you done so for me many times, you really need to ALWAYS ASK yourself, "Am I doing harm?"

    I just reloaded 13.1 B300612 and the Options switch "'Keep Original/Edited Label if Non-Empty" did not exist. The first file I opened in 13.1, GM went through the file and changed all my meticulously adjusted Feature Names back to this attribute concept, totally unknown to me. I stumbled upon the change immediately by dumb luck and I thought I had done something wrong. That file had many weeks of work invested in it and I could have lost all that time or worse published a map loaded with errors. Fortunately, I saved the 13.1 file under a new name out of an abundance of caution, so I should be able to recover in a few hours.

    Again, Do NO HARM!!!
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited March 2012
    I would certainly never intentionally do harm, but with the huge volume of changes it is inevitable there will be some issues. The main thing is that we fix them immediately when presented. In this case the option was there in B030612, it was just called 'Keep Original Label if Non-Empty' (I added the Edited text later to make it clearer but the functionality didn't change). GM hadn't lost any data, it was just choosing what to use for the label differently by default, checking that box would have shown all of your edited labels. That is why I now check it by default so that things look how they used to, even if it makes the new features a bit harder to get to.

    Of course with any important data I would definitely make sure you are making backups of all of your work since you never know what might happen, either from a bug in software or hardware failure. I would even suggest enabling the auto-backup option in the Advanced section of the General tab of the Configuration dialog so that you automatically get backup copies of your data as you make edits in Global Mapper, that way you won't lose any significant amount of work in case you lose power or Global Mapper crashes or something before you can save.

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
  • Roger EdrinnRoger Edrinn Global Mapper User Posts: 721Trusted User
    edited March 2012
    No one accused you of INTENTIONALLY doing harm.

    There's still a BUG.

    I can now edit the Feature Name either via the Edit Tool or the Feature Info Tool, however the same edit will not take in the Search Dialog. If I select one or more items, click Edit, the edited Feature Name is ignored.

    Can this be fixed?
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited March 2012
    Yep, found problem and fixed it, just an uninitialized variable. I have placed a new build at http://www.globalmapper.com/global_mapper13.zip with the latest changes for you to try. Simply download that file and extract the contents into your existing v13.xx installation folder to give it a try. If you are using the 64-bit v13 version there is a new build at http://www.globalmapper.com/global_mapper13_64bit.zip .

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
Sign In or Register to comment.