On Wed, Sep 21, 2016 at 8:05 PM, Matthias Kuhn wrote:
> I agree that we shouldn't ship broken things like this.
>
> Just a sidenote, I'm always very careful when reading "from a user
> perspective" as an argument in a discussion.
> I'm still looking for "the user" and the person who knows "the us
I agree that we shouldn't ship broken things like this.
Just a sidenote, I'm always very careful when reading "from a user
perspective" as an argument in a discussion.
I'm still looking for "the user" and the person who knows "the users
perspective" and couldn't find those two yet ;)
All the best
Mathieu Pellerin wrote
> Unless we have a feature parity with the current openstreetmap tool
> (offered through vector -> openstreetmap), please do not drop it.
From a user and software quality perspective, I think that we should not
ship a severely broken plugin as core plugin while the working Q
Mathieu Pellerin wrote
> Unless we have a feature parity with the current openstreetmap tool
> (offered through vector -> openstreetmap), please do not drop it.
>
>
> I agree with Mathieu. Perhaps it is possible to keep the first step of
> the download and redirect it to add it as a vector laye
2016-09-20 9:55 GMT+02:00 Mathieu Pellerin :
> One useful feature that isn't available through OGR (or QuickOSM last time
> I trieD) is the exporting of individual tags as fields (versus only
> creating a few fields and an "other_tags" field).
>
FYI, QuickOSM is not creating the "other_tags". The
Unless we have a feature parity with the current openstreetmap tool
(offered through vector -> openstreetmap), please do not drop it. One
useful feature that isn't available through OGR (or QuickOSM last time I
trieD) is the exporting of individual tags as fields (versus only creating
a few fields