Hi,
I'm trying to do something similar to the Get Feature Clicked on Code Example (wiki.thinkgeo.com/wiki/File:DesktopEditionSample_GetFeatureClickedOn_CS_100715.zip) in WPF but the GetFeaturesNearestTo function has different parameters (only has 4 overloads instead of 6)
Could you please check it?
Carlos.
Hi Carlos,
We checked the GetFeaturesNearestTo function and there are 6 overloaded methods in FeatureSource (Map Suite WPF Desktop Edition 4.5.0.0). Please check your version of Map Suite WPF Desktop Edition. Or send us your binary, we will check it.
For further research, could you please list the typical code you used? We don’t know if you used FeatureSource or QueryTools to get nearest features.
Regards,
Howard
Hi Howard,
The binary was ok 4.5.0.0, the problem was I was using QueryTools instead of FeatureSource. FeatureSource has 6 overloads and is fine. Why are they different?
I realized I have an additional problem: one of the function parameters is the columnname. I'm trying to identify a shape the user is clicked on, but the shapes was introduced with InMemoryTrackFeatureLayer.InternalFeatures.Add("TrackID=" & ElementID, New Feature(LS)) where LS is a lineshape created manually, then It never returns a feature.
Thanks,
Carlos.
I found that the problem was that I was trying to InMemoryTrackFeatureLayer.InternalFeatures.Add("TrackID=" & ElementID, New Feature(LS)) but the ID should be set to the Feature. I don't know why the New Feature(baseShape) is one of the few overloads that doesn't have the New Feature(baseShape, id) equivalent as the others.
I had to do a Feature(baseShape.GetWellKnownText, id) in order to convert it to WKT first and use this other construct.
Now it works as expected.
By the way, as I have hundreds of layers within the overlay I have to open them one by one and query on them one by one. It would be very very nice to have overlay-scope way of quering for features.
Hi Carlos,
For your first question; I think you are right about the difference between QueryTools and FeatureSource; they should be the same. Some of the API in the FeatureSource might be added later than the QueryTools and we forgot to synchronize them to the QueryTools. We will add it these two days; please check the latest DLL the package on Thursday this week.
I think you have figure out the issue for the second question that the feature is not added into the layer; the first parameter in the Add method is not the column for the feature. You can find the column parameter in the overload of the constructor of Feature class. Also it’s allow to add column values later using ColumnValues dictionary for the new feature. The reason is that the Feature class has 15 constructors recently, if we add every none Id parameter for all the constructor. There will be more. I will check with the core team later to see if we have a plan to add these new constructors.
It’s is a good suggestion to have the query and open method on the overlay. But you know Open method is on the Layer class which is reasonable to add on the LayerOverlay. While Query is only for FeatureLayer class; I think it is not proper to add into the layers because it maintains other layers than the FeatureLayer. So we will carefully consider to add open method. Hope it makes sense.
Just feel free to let us know if you have more queries.
Thanks,
Howard
Hi Howard,
If it is not possible to query the LayerOverlay, why to Open it?
I know that a LayerOverlay may have other kind of layers than FeatureLayers, but the Query could be restricted to them, such as LayerOverlay.FeatureLayers.QueryTools.
Regards,
Carlos.
BTW: Are you again on holidays in Europe?, or it’s because you prefer the night for the Forums ;)
One more thing regarding the constructors, the FeatureId can only be set on them, right? Then all the constructors should allow to add it, or it should exist a property or method to set it after creation if the non-id constructor was used.
Hi Carlos,
That's a good point to have a FeatureLayers property on the LayerOverlay. And I might misunderstand that you want a Open and QueryTools on the LayerOverlay directly. Please assume we have a FeatureLayers, then there are one Layers property and one FeatureLayers property which might confuse other users. They might think what is this new property doing. What if we use LayerOverlay.FeatureLayers.Add; we also can remove the Add method you know; but it is weird. As I think, the better idea to do extent the layers collection and do the querying.
Please copy the attached file to your project and use the code below to satisfy your requirement. Please choose any one of the following method. If it works fine, you can try to add any method you need in this extension.
layerOverlay.Layers.OfType<featurelayer>().GetAllFeatures(ReturningColumnsType.AllColumns);
layerOverlay.Layers.GetAllFeatures(ReturningColumnsType.AllColumns);
About the constructor; as you see, Feature is actually a structure and everything should be immutable; so there isn't a set property for the Id. I know there might be some structure pattern we didn't follow, but we need to do it like this for some reasons. I checked our API again and find there is only the constructors which accepts BaseShape doesn't have an id parameter. And we need keep the same Id for both BaseShape and Feature. So if you want to set the id of the Feature object and also have a BaseShape, please set id for the BaseShape instead. If we work as you mentioned, when we create the Feature with both BaseShape and Id, the id of the BaseShape parameter will be also changed and we cannot be sure if there is any side effects. Hope it makes sense.
BTW, it’s a part-time job for me on the forum temporary. So I will reply them when I’m online. There also be some guys during day time around. So just feel free to let us know if you have any queries.
Thanks,
Howard
</featurelayer>
FeatureLayerExtension.cs.txt (1.16 KB)
Dear Howard,
I’ll try your approach and come you back later with the results, but seems is a good idea.
You misunderstood me when I said you where on hollidays in Europe, what I was trying to express is my happiness because you was answering fast in european time (our morning, as when you were here), that in texas would be mid of the night, but reading it again it seems I’m complaining for delay in replyies (which is absolutely not the case). Sorry about that.
Hi Carlos,
That’s fine and I will try my best to satisfy your requirement when I’m available. You are so kind to explain and please don’t mind.
Just feel free to let us know if you have more queries.
Thanks,
Howard
Hi Howard,
When I use GetFeaturesNearestTo to get features close to, I give a point, and then I find features that are close to it. For the process I have to specify a buffer size (screen pixels). The method works fine for points or lineshapes, but for "icons" (styled point shapes), the buffer would vary depending on the icon size… So the question is: Is it possible having a screenpoint and an internalFeature to know if it "HitTest"?
In order to clarify:
Imagine you have a pointshape that is rendered as a 64x64 pixels icon, the "buffer" would be 32 pixels from the center of the icon, that is the external location, but for a 16x16 the buffer will need to be set to 8…
Carlos.
Actually, we have a Code Community sample that answers exactely that. Get the feature when clicking on the icon itself. It is a desktop sample but the principle still applies to other editions. It is called Identify Point with Icon. Please, check it out: wiki.thinkgeo.com/wiki/Map_Suite_De..._with_Icon
Hi Val,
That’s exactly what I need, even though my explanation was not fully clear. Thanks a lot!!!
Carlos
Thank Val.