Create locations using imported GPX files without making use of the drawing tools

[bjohare]

The problem

We need to be able to create Locations directly from imported GPX files without using the drawing tools. Attributes associated with a waypoint, route or track should be imported and used to assist the definition of the Location.

See here for detailed requirements.

Actual behavior

Currently, GPX layers are imported for display only and are used to assist the user to create Locations in conjunction with the drawing tools. No attributes are currently imported.

Expected behavior

Imported GPX layers should be used to create Locations directly. Attributes associated with waypoints, routes or tracks should be available during the definition of the Location.

[wonderchook]

@dpalomino this is something that needs to be put into the backlog for prioritization.

[dpalomino]

Hi @wonderchook. Sorry I missed this message. Yes, it was already included, item 3.04 in backlog. Brian and I were catching up on this some time ago.

For new locations I think this is a nice to have feature, but probably not super critical. However I think this could more important in the case of importing many locations boundaries previously collected (so it'd be very time consuming to "draw" the location with the assistance of the gpx layer).

I think there could be 3 possibilities:

1. The existing one, GPX data is displayed as an additional layer to assist in the creation of the geometry.
2. One step further could be to add a button in the drawing tools (for instance) to traspose or clone one boundary to create the geometry for one location (when we're adding a new location through the web user interface)
3. Importing a large number of geometries contained in a GPX file and creating new locations for each of them.

@bjohare @wonderchook, what do you think?

[wonderchook]

@dpalomino we should consider what the user is actually doing. Meaning beyond the GPX file type.

1. This one makes sense
2. I think in this case we'd want a button so the person could make a geom from the GPX, but then it would still be in edit mode so they could pull the boundary and adjust it.
3. In this case I would suspect the user is actually importing data and GPX isn't actually the ideal file type. They would probably end up with GPX just because we supported it. This would be better supported through the regular data import process probably.

[dpalomino]

Hi @wonderchook.

1. Perfect, this is the current behaviour
2. Agree, and that button would probably be in the drawing tools.
3. Yes, exactly. They will be importing data. However, some orgs already had the geometry data in GPX files. As a workaround, maybe we can try to convert these GPX files to one .csv file to go through the regular import process...

[wonderchook]

So I wouldn't expect that partners are storing their data in GPX permanently. I would suspect they have it in other types of files such as .shp or sqlite. Have you come across specific partners that have their data in GPX other than stuff directly downloaded off of GPS devices? @dpalomino

[dpalomino]

Hi @wonderchook. Yes, .shp is definitely more common, although there is one partner that was using GPX files for recording community boundaries. Not a high priority issue though.

[wonderchook]

@dpalomino regarding as in they stored it that way? How are they viewing them in Google Earth or something?

[dpalomino]

@wonderchook Not sure what they are using to view the GPX way tracks. They were just getting the GPX files from the GPS devices... But anyway I think it is not a high prioirty now.

[SteadyCadence]

Not sure if this fully related to the issue, but today Mabu wanted to upload a .gpx file and see how that works. The whole workflow is quite confusing. I think that when a user adds a location they should be able to choose if they want to trace the map, upload gpx or shapefile. Or something to that nature.

And then we would also need a way to support bulk uploads... Overall the current way the gpx uploads are set up is quite confusing.

[clash99]

@dpalomino is this a duplicate of #1590 or related?

[dpalomino]

Good catch @clash99! Closing the issue.