Improve the likelihood for Longitude and Latitude and having a coordinate for each Location

[skinkie]

As discussed in #777

The result of the discussion is that Longitude/Latitude should be set.. In DECK PLAN we have relative coordinates that need to be done with gml:pos. The documentation is adapted.

[skinkie]

It seems that Deckplan invented a relative grid. Decide what to do with that if WGS84 would be mandatory.

<DeckPathJunction version="any" id="rc:DPJ-slw_deck_1@forward_middle">
        <!-- locationgiven as offset from front left boundingbox of parent space or use projection  -->
        <Name>mid point at front fo carriage</Name>
        <Location>
                <gml:pos srsName="xy_in_Metres">3 2</gml:pos>
        </Location>
        <PublicUse>all</PublicUse>
        <PassengerSpaceRef version="any" ref="rc:PS-slw_deck_1@corridor"/>
</DeckPathJunction>

[Aurige]

That's more generic than DeckPlan (which is obviously not geographic): there is a specific need for any pathlink on a schematic maps that may not be geographic (that's an Indoor Mapping & Indoor Cartography issue). That's most probably useful for EPIAP too (a lot of underground maps and station maps are not geographic... there is also different habits: France tends to uses geographic maps, where UK often prefers schematic, non geographic, ones).

[skinkie]

That would either justify a different type, or not making WGS84 mandatory (or worse: the choice option).

[ue71603]

@Aurige My problems:

• The calculation of projectiond cannot be the duty of the data receiver in an European context.
• I don't want any geo localisaed object withouth geolocalisation.

I may accept that there are relative coordinates like deckplan. For indoor routing I think this ALL has to work with GPS as a baseline and therefore needs appropriate coordinates.

[Aurige]

I wanted to propose something like this (to make one of the location coordinate mandatory), but for some reason, it triggers validation issues (maybe an XMLSpy bug)

<xsd:complexType name="LocationStructure">
	<xsd:annotation>
		<xsd:documentation>Type for geospatial Position of a point. May be expressed in concrete WGS 84 Coordinates or any gml compatible point coordinates format.</xsd:documentation>
	</xsd:annotation>
	<xsd:sequence>
		<xsd:choice>
			<xsd:sequence>
				<xsd:group ref="WgsGroup"/>
				<xsd:element ref="gml:pos"/>
			</xsd:sequence>
			<xsd:sequence>
				<xsd:group ref="WgsGroup"/>
			</xsd:sequence>
			<xsd:sequence>
				<xsd:element ref="gml:pos"/>
			</xsd:sequence>
		</xsd:choice>
		<xsd:element name="Precision" type="DistanceType" minOccurs="0">
			<xsd:annotation>
				<xsd:documentation>Precision for point measurement. In meters.</xsd:documentation>
			</xsd:annotation>
		</xsd:element>
	</xsd:sequence>
	<xsd:attribute name="id" type="xsd:normalizedString">
		<xsd:annotation>
			<xsd:documentation>Identifier of point.</xsd:documentation>
		</xsd:annotation>
	</xsd:attribute>
	<xsd:attribute name="srsName" type="SrsNameType">
		<xsd:annotation>
			<xsd:documentation>identifier of data Reference system for geocodes if point is specified as gml compatible Coordinates. A gml value. If not specified taken from system configuration.</xsd:documentation>
		</xsd:annotation>
	</xsd:attribute>
</xsd:complexType>

[ue71603]

@Aurige You didn't put in the problem that occurs. I think it can't decide the path, does it?

[Aurige]

@Aurige You didn't put in the problem that occurs. I think it can't decide the path, does it?

I get this message... but I don't agree with it (but it does not validate so, no way). This Choice A/B/A+B is a classical one, I don't understand why it fails here

[Aurige]

We could go for <xsd:choice minOccurs="1" maxOccurs="2"... but then it also allows 2 WGS or 2 GML

[ue71603]

I fixed it already and it should now accept what we want with the last two commits. Is there still a problem? The ambiguous problem is: if there is e.g the wgsgroup. XMLSpy does not know from which branch of the schema this comes.

from the wgsgroup or gml:pos or the wgsgroup_only

It does not like that.

[Aurige]

That's all fine, well done !

[skinkie]

@ue71603 I really dislike how this is rendered into an api-interface. Have you checked that?

[ue71603]

@ue71603 I really dislike how this is rendered into an api-interface. Have you checked that? No idea what you are talking about.

[skinkie]

@ue71603 the python or java interface.

[Aurige]

Don't merge (due to code generation issue) ... or find a better solution Add comment about deprecating WGS Add a comment explicitly stating that a position is MANDATORY (GML or WGS for now)

• Doc updates

[skinkie]

My proposal would be to deprecate the Longitude and Latitude and only use gml:pos.