OcdFileExport: Zero angle on non-rotatable objects

[lpechacek]

Text and point objects with non-rotatable symbol appear orientated to north in Mapper. When writing XML, Mapper skips the rotation attribute in Object::save(QXmlStreamWriter&).

However, if a map is opened from OCD format, the north rotation lock is silently removed from point symbols. The user may restore the rotation lock by either replacing the symbol set or a manual intervention. Then if the map is saved in OCD format, the symbol has north orientation (rotation lock) and the object has rotation angle set. If the map is reopened in Mapper, the cycle repeats - there is a rotated object with a point symbol, so Mapper removes the lock again.

The text symbols do not have the rotation lock removal logic in OCD import and text appears rotated regardless of the lock setting. As a result, north oriented text is rendered as rotated and cannot be straightened by the Rotate pattern tool. The Rotate object tool, which is enabled for the object in question, creates funny effects.

This patch aligns the export logic in OCD export path with the XML counterpart.

[dl3sdo]

Text and point objects with non-rotatable symbol appear orientated to north in Mapper. When writing XML, Mapper skips the rotation attribute in Object::save(QXmlStreamWriter&).

Partly, due to text appears rotated regardless of the lock setting (as you pointed out), text objects with non-rotatable symbol don't always appear orientated to north in Mapper (but I propose to change that).

However, if a map is opened from OCD format, the north rotation lock is silently removed from point symbols. The user may restore the rotation lock by either replacing the symbol set or a manual intervention. Then if the map is saved in OCD format, the symbol has north orientation (rotation lock) and the object has rotation angle set. If the map is reopened in Mapper, the cycle repeats - there is a rotated object with a point symbol, so Mapper removes the lock again.

The north rotation lock is not always removed from the point symbol, it depends on the rotation value: only if there is a rotation, it's being removed (and thus the objects appears the same as in OCAD), with the exception in #2498.

The text symbols do not have the rotation lock removal logic in OCD import and text appears rotated regardless of the lock setting. As a result, north oriented text is rendered as rotated and cannot be straightened by the Rotate pattern tool. The Rotate object tool, which is enabled for the object in question, creates funny effects.

This patch aligns the export logic in OCD export path with the XML counterpart.

Yes, it does but the patch will also break OCD roundtrip: importing a rotated text object might result in loosing the rotation on export to OCD whereas for rotated point objects rotated point objects would always loose their rotation.

Right now there is an inconsistency especially for text objects:
If the text symbol is made rotatable, the text object is rotated and if then the text symbol is made not-rotatable, the text will still be rendered rotated (which is indeed confusing). Saving such a file as XML will remove the rotation value and thus the visual appearance will change on reopening, something which should not happen. For OCD export everything would be fine today (same visual appearance).
For point objects:
If the point symbol is made rotatable, the point object is rotated and if then the point symbol is made not-rotatable, the point will be rendered not-rotated. Saving such a file as XML will remove the rotation value and thus the visual appearance will not change on reopening. For OCD export the object would be exported rotated and thus the visual appearance would be different.

I propose to change the behavior in text appears rotated regardless of the lock setting to auto rotation_rad = symbol->isRotatable() ? text_object->getRotation() : qreal(0);
to align rendering of text objects with point objects.
If the text rendering change is applied, then applying your patch will

• lead to the same visual appearance in OCAD as in Mapper
• and align the export logic in OCD export path with the XML counterpart.

[lpechacek]

Thanks, Matthias, for your review and the thoughtful comment. At the same time I apologize for my delayed response as I had to make up my mind about my reply.

The object/pattern north orientation is where I diverge from the rest of the OO Mapper development team. I think that symbol north orientation means that the object with a north oriented symbol always points in the direction of the paper side edges. I've studied the orienteering map standards to support my belief and summarized my findings in #2373 (reply in thread) . For the matter of completeness, I consider the OCAD implementation with freely rotatable objects and patterns flawed. I'd rather support the original Mapper implementation where north oriented objects and pattern are always "straight" as this is how I understand the map standards on this matter. The alternate software (OO Mapper and LibreMapper for that purpose) should take the opportunity to warn the user when opening a non-compliant map and give the user tools to rectify the situation.

You've nicely summarized the current behavior, and I've extended the description in #2373 (comment) . In short, OO Mapper behavior differs for north oriented objects and patterns depending on the object type and file format. I'm not commenting on whether or not this is a desired state.

As you've pointed out, the patch here breaks the .ocd round trip for text object. That made me realize that the patch is in fact one of three patches in LibreMapper that implements my idea explained in the second paragraph. The patch series is as follows:

• LibreMapper/mapper@fdf00b5 - emits warning and removes rotation lock upon encounter with rotated objects and patterns
• LibreMapper/mapper@3081c2b - zeros rotation angle for non-rotatable objects in .ocd export (the patch here)
• LibreMapper/mapper@ca91b1e - makes text object respect the north orientation (implements your proposal, sitting in LibreMapper experimental branch)

The three patches implement what I think is a complete solution. When opening a non-compliant .ocd file, the user is notified about symbols whose objects rotated while they should oriented to north. The user can copy the list of warnings into a notepad and restore symbol north orientation lock by hand for all symbols where they deem it appropriate. As a result, the affected objects are "straightened" and that state is made permanent by saving the map to disk, regardless of the file format. Enough self-promo.

Ad your proposal for text objects. Making the text object rendering routines respect the north orientation lock will make a rotated text object appear north oriented in Mapper. Together with my patch, the north orientation will be permanent upon saving the map from OO Mapper to .ocd format. (It's now made permanent when saving in Mapper XML format.) However, the user is not notified about the fact that the text object was first rotated in OCAD. That is, the appearance will not be the same as in OCAD and the object will be "straightened" without the user knowing about it in the first place.

That, however, leads back to the basic question of whether OO Mapper should support the OCAD (IMO non-compliant) behavior and freely rotate all objects and patterns (the first step was made in #2378) or my simplistic "if it's north oriented, it points up" approach documented above.

Side notes:

• Warning about rotated symbols were first suggested in OcdFileImport: Handle rotated objects with rotation-locked symbols #2055.
• The use case in Losing "Hatch/Structure oriented to north when rotating the map" symbol property in Ocad files. #1677, which sparked the whole pattern and object north orientation review, was correctly supported with OO Mapper 0.9.5. The word "correctly" means "aligned with user expectations expressed in the issue report". Patterns weren't rotated in step 2, reverse rotation in OCAD worked as expected resulting in original object positions and pattern orientations after reverse rotation. This procedure is now altered with Mapper 0.9.6 as Mapper rotates the patterns in step 2.
• North orientation lock removal (without emitting a warning) was implemented for point symbols in commit 2cce659. It was never implemented for the other object types in OO Mapper.