feat(Base): Add some basic methods and configuration

[GuillaumeAmat]

Here are some basic methods to make a start on the project.

You can find a quick example of usage in the README. The main philosophy is to not store the elements. That way you can use the instance for a lot of actions without instanciating it everytime. but maybe it is not the right move... What do you think about that @PanierAvide?

TODO:

• Add the missing methods: send, close changeset, remove element, etc.
• Finish the README.md and the API.md

[coveralls]

Coverage decreased (-46.2%) to 53.774% when pulling 097e3679320beffc012666ef2aedf42352d3838c on feat/base into da9ab93a4fab91d753620874807fd184a6c87a4a on develop.

[PanierAvide]

Looks great :-) Just to be sure of the way it is implemented, so to edit a simple node, you have to:

• Fetch it with fetchElement
• Edit it with various methods
• And just create the changeset then send it

No need to specify that the node you edited should be part of the created changeset ? If so, this leads me to some questions:

• What if we manage several changesets at once ? This could be prohibited but might be documented
• What if we want to cancel edits on an object ? Will we have a cancel method or similar to reset element to its initial state ?

In fact, this implicit way of adding elements to changeset makes code lighter, but might be confusing. Maybe we need another opinion on this, @nlehuby what do you think ?

[GuillaumeAmat]

@PanierAvide

• Fetch it with fetchElement
• Edit it with various methods
• And just create the changeset then send it

Yep

No need to specify that the node you edited should be part of the created changeset ?

Yes it should! Actually, a changeset ID has to be part of the element(s) when you send it to OSM. In the changeset attribute.

If so, this leads me to some questions:

• What if we manage several changesets at once ? This could be prohibited but might be documented

I chose that approach to be compatible with that kind of behavior actually. The OsmRequest instance do not keep the elements and the changesets in its state. So it is the responsability of the user to keep the different elements/changeset ID safe on his side.

I had in mind that the send method could have two arguments, the element to send and a changeset ID to apply on. That way there is no constraints.

• What if we want to cancel edits on an object ? Will we have a cancel method or similar to reset element to its initial state ?

Same thing here, no black magic, it is the user responsability to keep the valuable data safe on his side. OsmRequest does not care about that.

[PanierAvide]

OK so it was quite the opposite of what I understood. OsmRequest instance is completely unaware of links between data and changeset, in order to let client handle that. The link between data and changeset is specified in node properties. So in fact it reflects directly the logic of the API, as a pure wrapper. Well, it makes more sense that way, and one can write its own abstraction library over this common base library. Good ! :-)

[GuillaumeAmat]

@PanierAvide The fetchNotes method is here! ;)