GetTraceData is accepting int instead of long?

[HarelM]

GetTraceData is accepting int, shouldn't it accept long like the rest of the API?

[HarelM]

@blackboxlogic any thoughts? I don't mind replacing the code from int to long but you might know something I don't...?

[blackboxlogic]

OsmSharp.API.GpxFile.Id is an int and I followed their lead without wondering if it was right. The API documentation isn't specific. I've just asked on dev channel in slack, waiting for an asnwer.

I foresee problems if we use long and OsmSharp.core uses and int. Probably best to try to fix both if you want to make the change.

[HarelM]

I see. Well, we'll need to do it in two steps - OsmSharp.core first and here later which will require two NuGet releases... :-/
If I needed to guess since this is a database key it's probably long. I'd be happy if you can take this one since you changed a lot of the classes in OsmSharp.core in the previous release.

[blackboxlogic]

Confirmed in slack by someone that sounded confident: it's a long. If there are no traces with large IDs, then you don't need to change OsmSharp.core. That would just be bonus points.

[blackboxlogic]

I'm noticing that element versions should also be long instead of int according to the db schema.

OsmSharp.OsmGeo.Version is currently an int? and should be a long?

Maybe worth fixing at the same time.

[blackboxlogic]

I've made OsmSharp/core#89 for the OsmSharp side of this.