This project has moved. For the latest updates, please go here.

Extension Methods - How to upload / suggest for the project

Mar 14, 2013 at 6:10 PM
Hey,
I'm new to CodePlex, so please forgive the ignorance. Our team has been working with SharpKml and has wanted some additional functionality for common tasks. To keep the source pure, I've been adding extension methods. I figure that they could be useful to other users, and I'm interested in contributing them back to the project (perhaps under a different namespace users can import).

How do I go about requesting to join the project or otherwise submitting suggestions?

PS: I'm including a couple examples below. These are all works in progress - I would clean them up before submitting.
/// <summary>
/// Gets the style information for this placemark of type T.
/// </summary>
/// <typeparam name="T">The type of style information requested (e.g. IconStyle)</typeparam>
/// <param name="placemark"></param>
/// <returns></returns>
public static T GetStyle<T>(this Placemark placemark) where T : ColorStyle
{
    if (placemark.StyleSelector != null)
    {
        //attempt to find a style of type T in this style selector
        StyleSelector s = placemark.StyleSelector;
        //Debug.Log("Got a style selector: " + s.GetType());
        if (s is Style)
        {
            PropertyInfo[] pInfos = typeof(Style).GetProperties(BindingFlags.DeclaredOnly | BindingFlags.Public | BindingFlags.Instance);
            foreach (PropertyInfo pInfo in pInfos)
            {
                if (pInfo.PropertyType == typeof(T))
                {
                    T style = (T)pInfo.GetValue((s as Style), null);
                    return style;
                }
            }
        }
        //should implement for other kinds of styleselectors...
    }

    //nothing found
    return null;
}

/// <summary>
/// Removes all style information of a given type (e.g. IconStyle or LabelStyle)
/// </summary>
/// <typeparam name="T">The type of style to remove</typeparam>
/// <param name="placemark"></param>
public static void ClearStyle<T>(this Placemark placemark) where T : ColorStyle
{
    if (placemark.StyleSelector != null)
    {
        //attempt to find a style of type T in this style selector
        StyleSelector s = placemark.StyleSelector;
        if (s is Style)
        {
            PropertyInfo[] pInfos = typeof(Style).GetProperties(BindingFlags.DeclaredOnly | BindingFlags.Public | BindingFlags.Instance);
            foreach (PropertyInfo pInfo in pInfos)
            {
                if (pInfo.PropertyType == typeof(T))
                {
                    pInfo.SetValue((s as Style), null, null);
                }
            }
        }
    }
}
Coordinator
Mar 14, 2013 at 10:46 PM
Thanks for the kind offer!

I'll be honest I'm not sure what the best way to upload your changes is! On the SOURCE CODE tab there is an option to upload a patch or, if you prefer, feel free to email me (you can do that by clicking on my profile and then Contact on the left hand side) and you can send me a zip of the files and I'll be happy to introduce them into the library to help others.

Sam
Mar 15, 2013 at 5:32 AM
Thanks Sam!

I'll definitely send you some stuff a little later on. We're going to be doing additional KML development over the next couple of weeks, and then I'm off for vacation, so it might be a little while before I send you a package of suggested functions.

-Julien
Apr 26, 2013 at 7:19 PM
Sam,

Just got back from vacation, and I'm hard at work implementing SharpKml in our visualization tool.

I'm not quite ready to upload my extension methods - they're still a work in progress. However, I do have a bugfix and improvement for the StyleResolver.

Bugfix: The style resolver doesn't keep any context on which KmlFile it's working with. So, if you have a styleUrl that references a remote KmlFile, and then within that file the target of the styleUrl references another style within the same file, StyleResolver will follow the link to the new file, but then look for the second reference back in the original KmlFile. My quick and dirty solution is to pass around the current KmlFile rather than using the internal _styleMap variable that saved from the StyleResolver constructor. Feel free to improve upon it if it's not elegant enough :)

Improvement: The StyleResolver will follow styleUrls to remote files if _resolveExternal is true. It uses the built-in FileHandler.ReadFile() method to do so. One downside is that if you have thousands of external styleUrls, it'll grab the remote file each time, and then throw away the reference. I added a _kmlFileFetcher delegate that the user can pass to StyleResolver. If defined, StyleResolver will call this delegate and allow the user to return the appropriate KmlFile; if not defined, it will use the default FileHandler.ReadFile to grab the KmlFile.

I'll try to add the changes as a patch.

-Julien
Coordinator
Apr 26, 2013 at 9:06 PM
Thanks for that Julien! I'll take a look at the patch over the weekend and get it applied to the latest version.

Sam
Apr 30, 2013 at 8:36 PM
Hey Sam, new question for you:

In the SharpKml definition, you include 3 types of bounding boxes:
LatLonBox,
LatLonAltBox,
BoundingBox

The first two are a part of the KML spec, but the third is not, as far as I can tell. It looks like it's only being used in the geometry and feature extensions. I can see the advantage in the various calculation methods you've defined in the BoundingBox class, but what's the logic in making a whole new class? What are the disadvantages in, say, extending BoundingBox from AbstractLatLonBox, or defining extension methods for LatLonBox the work under the assumption that rotation is 0, or defining extension methods for LatLonAltBox that just ignore the altitude component (rotation is always 0 for LatLonAltBox)?

Thanks!
-Julien
Coordinator
Apr 30, 2013 at 10:32 PM
Can't remember to be honest, but I have a feeling it was to match the libkml implementation. Also by not inheriting from AbstractLatLonBox there is a separation from the what's part of the KML specification and what's specific to this library.

I guess I could add some explicit conversions to/from LatLon(Alt)Box so you could cast a BoundingBox to one used by KML if you think that would help?
Apr 30, 2013 at 11:47 PM
Nah, that's okay. It was just a bit confusing since BoundingBox was the first one I came across. Having separation does make sense.

We're still working on KML for our tool, so I'm still poking around, creating extension methods as needed. In a few weeks I'll separate out the ones I think could be most useful and upload them for you to decide if you want to add them into the base library.