willowlark / kml-optimizer-pathfinder Goto Github PK

Going to streamline the output functions for geometrics and add support for alternate coordinate inputs in urlbuilder.

Making sure all functionality supports polygons, including the fact that polygons can have multiple geometry tags.

The Description tag exists for all placemarks. These descriptions are the most likely place for any information about the geometry to be stored. We will want to display this information with the geometry, and it must be pulled out to do so.

• Could be stored in either geometries (could cause issues with multigeos, fixed possible from #20 ) or
• pulled with the placemarks.
• A third option might be using the element stored in the geometric to pull the description later.

Google maps api does not do partial filling with our split url solution space. We'd like to provide that feature despite it. Current theory is to analyze the base and merged images, and if a pixel has a modified pixel to the N, W, E, and S directions, it should be tinted.

Funny thing, this is kind of implemented. Cleanest design would be to create an extension of KMLFasade that uses multiple KMLFasade to provide data, and an extension for the classes in StaticMaps package in the same vein.

Giving the Fasade the ability to add a given point, line string, or linearring. Polygon support possible.

The are two bugs minor to the console interface that could be fixed.

The loop that pairs up data and flags isn't very smart. It doesn't do well with

• switches with no data at the end of the the parse list are parsed with the input file as their data.
• optional data arguments aren't processed well.

They aren't detrimental bugs, but should be fixed at some point.

URL for creating overlay can not hold enough parameters for actual KML files that will be used. We need to find an alternative way to create an image with the KML overlay

Basically run through some kml files containing object within the multigeometry tag and make sure they doesn't unecessarily remove data. Debuggers r ur friend

The stack implementation in clipper is pretty much a wrapper around a list; unless there a reason to keep the wrapper, best remove it for simplicity.

Find a way to minimize the amount of display information. May involve:

• Removing points from a multi-coordinate geometry that have no lines that are with in filter radius.
• closing line strings made from the above so they have polygon support (make them paths)
• Adding points to create a new object that is completely contained in filtered radius.

Right now, while the lines internally are drawn right, we have a small issue where Q is traced all the way around the outside. Has something to do with the trace algorithm. While it's not completely detrimental, it's possibly troublesome.

KML Fasade needs to strip excess data from a given kml file. Tags such as styleUrl, Style, Lookat, visibility, screenoverlay, tessellate, altitudemode and extrude do not provide any useful data. These should be removed to reduce the size of the kml.

Our view is defined by the zoom parameter, which we can now get the exact distance of. It is possible that we could reduce the filtering size provided down to the zoom parameter, as anything larger wouldn't be shown anyway. Needs some theorizing, but a possible workload reduction.

Removing as much data as possible from the KML file to reduce file length. Preferrably this should be more detailed than the clipping for Static Maps.

Calculate the distance a zoom level displays from google maps static, find out out large of a filter is needed in a radial filter to cover that entire area.

A module that will allow for easy driver building. Will be built like a linux console command, parameters, switches, the works.

Static Maps really doesn't like us calling for 181 images. We won't need to do that all the time, but we need to find a formula that will prevent maps from kicking us for x period of time.