jumpinjackie / mapguide-maestro

MapGuide Maestro
https://jumpinjackie.github.io/mapguide-maestro/
27 stars 20 forks source link

System.MissingFieldException - Wrong GEOMETRY field name #99

Closed jumpinjackie closed 3 years ago

jumpinjackie commented 3 years ago

@Crispin-at-Linknode wrote:

I hope you can see the image... I have transferred some code to a new WinServer2019 and MG 3.1.2 server and matched the Maestro API ... we have a drill-down point selector (to find all objects under a click, not just the top one). But the Maestro API is throwing an exception, like it hasn't resolved the "GEOMETRY" field properly?

Any help appreciated - not sure if it needs a API fix?

image

jumpinjackie commented 3 years ago

Are you using MaestroAPI built from source or from the nuget package?

If nuget package, what package version? If from source, is it current git master HEAD?

Crispin-at-Linknode commented 3 years ago

I am using the nuget latest, using VS2019 nuget manager (3.1.2.9484) I have just loaded source so will try and link to that once I get the build working

Crispin-at-Linknode commented 3 years ago

When I build the Maesto API from source I get two issues: I don't get a MaestroAPI.http.dll I get an GetLegendImageStream is unimplemented when I mix a MaestroAPI.http.dll with my own build

jumpinjackie commented 3 years ago

Regarding no MaestroAPI.http.dll anymore, that's because the HTTP connection provider has been folded into the MaestroAPI library itself.

jumpinjackie commented 3 years ago

GetLegendImageStream unimplemented is weird, because it is implemented right here!

mg-desktop wrapper: https://github.com/jumpinjackie/mapguide-maestro/blob/ce0158e4e7edca7bb47437cfee62a8c06828624a/OSGeo.MapGuide.MaestroAPI.Local/LocalConnection.cs#L1213

roll-your-own MapGuide API wrapper: https://github.com/jumpinjackie/mapguide-maestro/blob/ce0158e4e7edca7bb47437cfee62a8c06828624a/OSGeo.MapGuide.MaestroAPI.Native/LocalNativeConnection.cs#L912

http implementation: https://github.com/jumpinjackie/mapguide-maestro/blob/ce0158e4e7edca7bb47437cfee62a8c06828624a/OSGeo.MapGuide.MaestroAPI/Http/HttpServerConnection.cs#L1581

Crispin-at-Linknode commented 3 years ago

Yes,,, I saw all those... but something in runtime didn't pick up the right DLL ?

Difficult to get messages etc as all on a remote VPN login/desktop but the reason I has to add the Maestro.http DLL back in from the Nuget package was that I got a compiler error that the class was inaccessible (protected?) when I used just the MaestroAPI (and ObjectModel) included directly with the project. There are obviously some differences with the Nuget (3.1.2.9484) and the build from git head because of the output DLLs... -- I also tried to update all the nuget package references but then got in a real mess as GeoAPI and NetTopologySuite start arguing about who owns which class in the code... but that's another story.

Plan is to go back to including the MaestoAPI and ObjectModel as project references in my solution and report from that point later.

jumpinjackie commented 3 years ago

If we work from the starting point that GeoAPI and NTS are not cooperating, then I already have a work-in-progress .net 5.0 feature branch that already updated NTS and gets rid of GeoAPI. I'll try to graft out these changes back into master and try to get new nuget packages up afterwards

Crispin-at-Linknode commented 3 years ago

I see your "feature/package-updates-2109" branch commits ongoing

Crispin-at-Linknode commented 3 years ago

Hi - sorry I can't apply latest merge to my environment until I request a firewall relaxation again for http. But I have gone back and built test project again directly against MaestroAPI.

My issue throws trying to initialise FixedWBKBReader()... but any break points in the constructor are not hit so I don't really understand why.

The trace is effectively: conn.FeatureService.QueryFeatureSource(...) which in QueryFeatureSourceCore(...) creates a WebRequest = ...SelectFeatures(...) which tries to return a new XmlFeatureReader(resp)

I can confirm that getting the actual HTTP request from reqAsUrl(...) returns an XML as expected from the MG Server.

image

jumpinjackie commented 3 years ago

What does your AppDomain loaded assemblies look like before the FixedWKTReader is new()'d?

This is the AppDomain of a test exercising the FixedWKTReader (before the package update merge, at commit: ce0158e4e7edca7bb47437cfee62a8c06828624a)

2021-09-09 19_35_42-QuickWatch

Does your AppDomain have these assemblies and with versions that correspond to whatever versions you are expecting?

Crispin-at-Linknode commented 3 years ago

Ah... maybe a useful helper. All is well apart from NTS which is showing 2.x in the assemblies. A look at the NuGet consolidate shows the Maestro project uses 1.15.3 but my main application is on 2.3 -- and the DLL within the \bin folder is the v2.3 one ... I will now try and get the source head updates from your last merge.

Crispin-at-Linknode commented 3 years ago

Hi, Included the API and ObjectModel projects from source (head) with the updated NuGet for NTS and all is good again. Excellent. Case closed. Thank you for support.

One observation (possibly intended behaviour?) is that it is possible to pass a list (array) of property names as an override into: FeatureService.QueryFearureSource(...)

However, if one of the property names is a geometry field then within: MaestroAPI\Schema\PropertyDefinitions.cs (line 260) PropertyDefinition Parse(...)

it will throw an Exception Maybe OK... but a geometry is a Property so a clearer Exception or handling would help?

jumpinjackie commented 2 years ago

Just a heads up @Crispin-at-Linknode

I added this test case and could not reproduce the exception. Which has lead me to believe that the condition on this line is not being hit for your particular case.

If you care the pursue this issue any further, I'm interested in what the value of the type attribute for your geometry property is. I suspect it may be missing the gml: prefix or the geometry type string is completely different.