Cannot farm land can be used for crops for some time, and then milk
cattle for some other period of time?
IIRC that is what one of my relatives did.
On 18/08/19 11:20, Leif Rasmussen wrote:
But isn't that the definition of farmland in OSM? I would map meadows,
farmyards, and orchards with
But isn't that the definition of farmland in OSM? I would map meadows,
farmyards, and orchards with their respective tags, not with
landuse=farmland.
Leif R
On Sat, Aug 17, 2019 at 7:18 PM Joseph Eisenberg
wrote:
> Produce=crop would be worse, because “crop” is not a type of produce, and
>
Produce=crop would be worse, because “crop” is not a type of produce, and
produce= is only very rarely used for crop land ( crop= is the established
key for types of crops like rice, sugarcane, wheat, etc)
As I mentioned on the Talk:Key:crop page, I suspect that this tag crop=yes
is sometimes
sent from a phone
> On 17. Aug 2019, at 22:36, ael wrote:
>
> But do we have any generic terms already? Unless
> you just mean office.
businesses can already be found in amenity (e.g. food and drink, pharmacies,
post offices, prisons (US), etc.), tourism, leisure, shop, craft, office,
sent from a phone
> On 17. Aug 2019, at 17:09, Mateusz Konieczny wrote:
>
> 9326 of 9657 crop=yes is on landuse=farmland - it seems to me that it is
> not adding any information whatsoever.
certainly removing them would be even less useful? You could read it as a way
of stating that
On Sat, 17 Aug 2019 at 16:12, Mateusz Konieczny
wrote:
9326 of 9657 crop=yes is on landuse=farmland - it seems to me that it is
> not adding any information whatsoever.
>
Some farmland is used to grow crops. Some farmland is used to graze sheep
or cows. So not entirely useless, but perhaps
sent from a phone
> On 17. Aug 2019, at 15:18, Paul Allen wrote:
>
> Also out of courtesy.
yes, there may always be considerations from individual mappers to refrain from
mapping certain things , for different reasons like courtesy, respect etc., and
this is perfectly fine (more difficult
sent from a phone
> On 17. Aug 2019, at 13:49, Joseph Eisenberg
> wrote:
>
>
> I restarted the thread more recently with a specific example:
> craft=atelier had just been documented after being used a dozen times,
> and was added to the Key:craft page and to Map Features. My question
> is:
Is there any situation where crop=yes should not be removed as utterly useless?
9326 of 9657 crop=yes is on landuse=farmland - it seems to me that it is
not adding any information whatsoever.
https://taginfo.openstreetmap.org/tags/crop=yes#map
Again, software can not handle e.g. the E2 relation. Simple sort, fine,
bridge a small gap, handle a roundabout, fine, but not the more serious
route-breaking issues. You can't expect Garmin to solve that, it's a data
issue in OSM. Currently the only way to solve it is making the data
flawless:
In this case, I do NOT want to go from A to B. I want to do the hike, that
is the route, exactly as it is specified OSM. Those ways, in the exact
order. I want my smartphone or garmin to guide me exactly along those ways,
which were carefully picked when the route was entered into OSM.
If that
I agree with Andy Townsend here.
Routes are complicated enough without needing to be always perfectly
sorted. Software developers and database users should make up for
this. Mapping is hard and takes precious human time. Computational
cycles are cheap.
OSM has never been designed to be used
If there's just information on paper or web, I wouldn't map it. If there is
just an information board with a map, I would map that as
tourist=information.
I only map if there is actually something on the ground that shows where
the route is. How accurate and adequate that is, is another matter.
> You want to do the routing. I want to avoid that, because the routing has already been done. To be clear, I want to navigate from where I currently am to where
On Sat, 17 Aug 2019 at 14:05, s8evq wrote:
>
> On Fri, 16 Aug 2019 20:00:32 +0100, Paul Allen wrote:
> >
> > Does it have to be signposted as a walking route?
>
>
> In my opinion yes. It's an objective fact, visible on the ground, and can
> be verified.
> Let's put it otherwise: "Besides signs
Your viewpoint is different from mine. You want to do the routing. I want
to avoid that, because the routing has already been done. The OSM-relation
IS a route. It is entered as an exact chain of ways to folllow.
OsmAnd and Garmin should take the route itself, not waypoints to route to.
It is odd
On Sat, 17 Aug 2019 10:58:36 +0900, Joseph Eisenberg
wrote:
> It is better to document the meaning of a property tag at its own wiki
> page, so tools like Taginfo can make use of the description, but a tag used
> only a handful of times does not need to be added to major feature pages
>
On Fri, 16 Aug 2019 16:18:38 -0400, Jmapb via Tagging
wrote:
> - Speaking of "yellow", the table specifies that colour should be a
> hex triplet, but wiki page for the colour key indicates that named HTML
> colours are also acceptable values. And I know many trails are tagged
> this way. So
On Sat, 17 Aug 2019 at 13:28, Martin Koppenhoefer
wrote:
>
> you have mentioned the owner’s wishes already yesterday, but I wasn’t
> aware we had a requirement that the owners must tolerate having their
> property mapped.
We don't (that I know of).
> So far I thought the only strict
> apps like OsmAnd, Garmin devices, and planner applicationsI can answer the Garmin bit of that, as it's something that I do all the time.Firstly, the ability to
On Fri, 16 Aug 2019 20:00:32 +0100, Paul Allen wrote:
> On Fri, 16 Aug 2019 at 19:43, s8evq wrote:
>
> > [1] [make it more clear that the walking route has to be signed in order
> > to map it. As it is stated now, you could read it that a named hiking route
> > is sufficient to be mapped]
> >
The sequence of the component ways in a walking/hiking route relation is
irrelevant for a hiker who use a navigation device to walk along the route.
Why?
How do you walk a walking route with a navigation device?
Basically you have two options:
A) you have prepared beforehand a GPX track, typically
sent from a phone
> On 17. Aug 2019, at 13:22, Paul Allen wrote:
>
> But also no need not to map them should the
> owners wish.
you have mentioned the owner’s wishes already yesterday, but I wasn’t aware we
had a requirement that the owners must tolerate having their property mapped.
So
I would like to use walking route relations as they are in OSM, in apps
like OsmAnd, Garmin devices, and planner applications. Currently, you
can't. As far as I can see, they all re-route instead of using an already
available route (= chain of ways). I would like to see unbroken elevation
On Sat, 17 Aug 2019 at 12:53, Joseph Eisenberg
wrote:
That is, should wiki users and mappers feel free to add any newly
> documented values of craft=, shop=, building=, office=, and sport= to
> the Map Features wiki page, and the Key page (eg Key:office,
> Key:craft), or should this always be
On Sat, 17 Aug 2019 at 12:42, ael wrote:
>
> I would be all in favour of introducing "business" as long as it was
> not restricted in that way. Easy with various values. It might
> gradually evole and get used properly and gradually outnumber the old
> misused office tag. Should not be too
This thread actually started with the question in the title:
"Keys to which new values can be added (to Map Features) without a
proposal: craft=, shop=, building=, office=, sport=?"
That is, should wiki users and mappers feel free to add any newly
documented values of craft=, shop=, building=,
On Sat, Aug 17, 2019 at 12:27:22PM +0100, Paul Allen wrote:
> It's both. Perhaps, with hindsight, most would agree that is sub-optimal
> but that's
> the way it is. More importantly, it's been that way for long enough that
> fixing it is
> probably not possible.
Unfortunately, you are probably
You haven't answered the question - I asked "Where are you going from and where are you going to?" in order to try and understand what real-life problem you're trying to solve. "I would like the ways of a relation to be sorted" is not a real-life problem. What navigation software are you using
On Sat, 17 Aug 2019 at 11:55, ael wrote:
>
> But surely parcels are seldom delivered to an "office" but typically to
> reception in a business. Of course, reception may be part of an office,
> especially in small organisations.
>
I'd normally class a reception as part of the larger organization
On Sat, 17 Aug 2019 at 01:55, Warin <61sundow...@gmail.com> wrote:
> On 17/08/19 07:54, Paul Allen wrote:
>
> On Fri, 16 Aug 2019 at 22:33, Martin Koppenhoefer
> wrote:
>
> That said, in the few cases like that where a company doesn't specifically
> make its location
> public knowledge, if I
Op za 17 aug. 2019 om 12:31 schreef Andy Townsend :
> > but I would like to see one make a plausible navigation route out of the
> E2 Yorkshire relation as it is now.
>
> Where are you going from and where are you going to? Without that
> information "make a plausible navigation route out of the
On Fri, Aug 16, 2019 at 10:54:52PM +0100, Paul Allen wrote:
> On Fri, 16 Aug 2019 at 22:33, Martin Koppenhoefer
> wrote:
>
> >
> > The way I see it, we’re mapping the world, as it is. Not just places where
> > the general public may have an interest in navigating to it. If you were to
> > make
The issue here is that these relations are there, they conform to current
wiki documentation, but you can't simply use them in applications other
then for rendering. Some of the issues (sorting, bridge simple gaps) may be
solved with software at the data user's side, but on the whole you can't
> but I would like to see one make a plausible navigation route out of the E2
> Yorkshire relation as it is now.
Where are you going from and where are you going to? Without that information
"make a plausible navigation route out of the E2 Yorkshire relation" makes no
sense.
You could
Two routes, currently mapped together in one relation, but also containing
subrelations, and not in the right order, and the total of that is part of a
higher relation which also has variants. You can’t blame the route designers,
you simply have to accommodate the real life variations. For
On 17/08/2019 07:28, Peter Elderson wrote:
Gpx gaps in some software do show up as straight lines. If it's just a
missing piece and the rest is in order, no problem. In the case of the
E2 in Yorkshire, lots of straight lines. Feed that to a navigation
device and it will have you start in
Peter Elderson wrote:
> I would like to see this software in operation! Could you give me the
> links of some applications
I use my code in the backend of cycle.travel. It's not open source. I've
seen code used by one other OSM-based site and there's a further one that's
clearly using something
I know how to fix these issues. The point is, as it is it's not good
enough for data use besides rendering. you can't rely on route relations
for anything but rendering, and you can't fix that with software. It's not
a tagging issue, though.
Gpx gaps in some software do show up as straight
39 matches
Mail list logo