--attr-prefix flags

[rclark]

• exposes a CLI flag that allows the user to specify a prefix for openstreetmap attributes that are placed into geojson .properties
• if not specified, uses a default value of @ for the prefix
• adds type and id prefixed properties to replace what was _osm_node_id etc.

Todo:

• add top-level id to geojson features like n1234, w5678, a1023 to give each feature a unique, osmium-defined id.

fixes #11

---

@joto I am very new to writing c++ so please critique everything about this. In addition here are some specific questions that I had:

• when an Area is passed to .add_properties I would like to make use of the .orig_id and .from_way methods. Is there a way to coerce the osmium::OSMObject reference passed to the function into an Area that would avoid this mess?
• is there a better way than this to concatenate strings and pass them off as char*?
• I don't understand what's different about the JSONHandler in these two cases: why am I able to set the instance-level m_attr_prefix variable in one way in minjur.cpp, but need to set its value differently in minjur-mp? What am I doing differently in these two cases?

[springmeyer]

@rclark did you mean to check in the d.diff file?

[rclark]

derp! Definitely did not mean to do that. Rebased it away -- thanks @springmeyer.

[joto]

@rclark Thanks. Generally this looks very good. You already indentified most of the issues yourself and I have tried to answer them in the inline comments. I have been extra picky with my comments, because I think that way you can learn fastest. Ping me on chat if you need extra explanations of those tricky C++ details like the initialization of the class membery variables. That's pretty unintuitive stuff if you have never seen it before, but will become second nature after a while.

[rclark]

I ended up getting the static_cast to work as follows:

static_cast<const osmium::Area&>(object).from_way()

Needed the const, as you suggested @joto, but also needed the &. My "clue" was from http://en.cppreference.com/w/cpp/language/static_cast:

If new_type is a pointer or reference to some class D and the type of expression is a pointer or reference to its non-virtual base B, static_cast performs a downcast.

Saw "reference" and thought "maybe I need an &", but honestly I can't say I entirely understand why this was successful. Is this just about making a 100% match to the way that object was defined (as const osmium::OSMObject&)?

---

At this point, aside from the fact that this code still concatenates strings on each .add_properties call, I think I've hit all you points. Thanks for the review and maybe we can merge now?

[joto]

@rclark The static_cast allows you to pretend some object is of some other type. But it doesn't just allow any kind of pretending, just some things that are, if done properly, safe and make sense. In this case the original object is of type const OSMObject& (a reference to a constant OSMObject). You can only cast this to a class type that is a) a reference, b) constant, c) derives from OSMObject, so const Area& is okay. If you leave out the const you would make the object mutable, which is not allowed (there is a const_cast for that, if it is really needed, but normally you should not use that). If your original type is OSMObject& without the const, you can add one, because that is a further restriction, that's okay. But you can't remove the restriction. If you leave out the & you would make the reference into a real "value" of the object, which doesn't make any sense. Hope this clear things up.