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
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
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
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
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
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
Dear all,
This topic pops up regularly on the mailing lists, but nothing happened lately.
The OS import tool is still not able to load features with node numbers exceeding the 32bit-unsigned limit, see http://wiki.openstreetmap.org/wiki/64-bit_Identifiers . As a consequence, features get