CartographicText style doesn't work about osmm-topography-layer-stylesheets HOT 9 CLOSED

FWIW I feel that the ESRI tools should probably change inline with the OS styles and SQL.

The styles and SQL scripts in this repo have set the convention other loading tools are following. The derived columns colour_code etc. are used consistently in the v9 styles including SLD and QML.

from osmm-topography-layer-stylesheets.

Fair comment Matt, I'll take it up with ESRI and close this issue.

from osmm-topography-layer-stylesheets.

I'm reopening this because whilst the derived column colour_code is consistently used in the v9 styles and SQL (and it's the ESRI tool that's adding color_code incorrectly), the height and textstring are not being modified by the ESRI tool. The actual attributes supplied by OS are TextHeight and Text, so I'm of the opinion the stylesheets should match the data in these cases and need updating.

Happy to be corrected if I've misunderstood.

from osmm-topography-layer-stylesheets.

Hi @ianholmes

In your comment you say "the actual attributes supplied by OS are TextHeight and Text". Looking at the GML of a CartographicText feature it contains textstring and height.

<osgb:CartographicText fid='osgb5000005223020018'>
osgb:featureCode10059</osgb:featureCode>
osgb:version1</osgb:version>
osgb:versionDate2018-02-19</osgb:versionDate>
osgb:themeLand</osgb:theme>
osgb:anchorPoint
<gml:Point srsName='osgb:BNG'>
gml:coordinates464240.720,154447.090</gml:coordinates>
</gml:Point>
</osgb:anchorPoint>
osgb:changeHistory
osgb:changeDate2018-02-13</osgb:changeDate>
osgb:reasonForChangeNew</osgb:reasonForChange>
</osgb:changeHistory>
osgb:descriptiveGroupGeneral Surface</osgb:descriptiveGroup>
osgb:makeManmade</osgb:make>
osgb:physicalLevel50</osgb:physicalLevel>
osgb:textRendering
osgb:anchorPosition0</osgb:anchorPosition>
osgb:font1</osgb:font>
osgb:height1.5</osgb:height>
osgb:orientation0</osgb:orientation>
</osgb:textRendering>
osgb:textStringPlay Area</osgb:textString>
</osgb:CartographicText>
</osgb:cartographicMember>

So I am wondering if ProductivitySuite is processing those fields as well.

Is there a way to use Productivity Suite without applying the styling bit and leaving the data as was?

from osmm-topography-layer-stylesheets.

Hi @TimJMartin, thanks for the response. You're absolutely right, the raw GML has Height and TextString, but once it's processed through Productivity Suite in to a FileGeodatabase they become TextHeight and Text.

I've had another look through all the settings in Productivity Suite and there doesn't seem to be any way of controlling this.

So, I guess the fault/issue lies with Productivity Suite. Not sure I'll be able to persuade ESRI to change it but I could give it a try...

from osmm-topography-layer-stylesheets.

@ianholmes

It is a difficult situation. We created this repo to try and standardise the attribute names as we saw that many different translators did different things especially if the export format also forced the issue. For example ESRI Shapefile having a limit of 10 characters would mean descriptivegroup become descgroup or desc_group. This made life impossible for our GeoDataVz team to create and support the stylesheets as there were too many permutations.

I believe Productivity Suite is getting a face lift not sure what those might be but maybe worth an ask.

Alternatively if our style LYR file can be edited to look for Text and TextHeight then we could include an additional version in the repo for others.

from osmm-topography-layer-stylesheets.

Hi all

I am the Product Manager at Esri UK that looks after ProductivitySuite and it's replacement UK data Loader.

We are working on the Topography loader at the moment so I will have a look into this to see if we can change it in the new loader to line up with names the layers file are expecting.

To minimise the impact on people of moving to the new loader we have been, where possible, keeping the names and attributes the same as those produced by ProductivitySuite. A consequence of ProductivitySuite being used for data loading for such a long time is that people have built up systems and processes around featureclasses and attribute names being set to certain things.

This doesn't seem like it would impact too many people and would make it easier to integrate with these layer files.

I will have a chat with the team and let you know

Peter

from osmm-topography-layer-stylesheets.

Hi @petermcdaid

Thanks for your message.

That sounds promising. If there is anything we can do to help or test just let us know

Thanks

Tim

from osmm-topography-layer-stylesheets.

Thanks @petermcdaid and @TimJMartin, likewise please let me know if there is anything we can do to help or if you want anything tested.

Cheers - Ian.

from osmm-topography-layer-stylesheets.