Sorry for jumping in late and likely breaking the threading.
But given that I'm likely one of the largest users of the JOSM format
presets outside of the JOSM devs and maintain my own fork of the default
JOSM preset ( https://github.com/simonpoole/beautified-JOSM-preset ) I
do have a couple of
On that topic: I'm trying to convince the iD maintainers to at least
move all projects that are on transifex in to the OpenStreetMap
transifex organisation so that we can share translation memory.
Naturally this doesn't apply just to editors, essentially we should be
using, as far possible, the
If the JOSM devs really want to move away from launchpad, surely the
choice should be between an existing service (transifex and others) or
running (and potentially improving if there are missing features) an
existing system (for example Pootle) and not wasting effort on yet
another ..
On a slight deviation from the original topic, as you may know, the
other consumer of JOSM style presets is Vespucci. The upcoming 0.9.7
release will support translated presets, given the different platform
and other constraints, this is based on GnuText .pot and .po files.
In any case if you
A couple of weeks back, see https://josm.openstreetmap.de/ticket/12412 ,
explicit support for multipolygons was added to the presets.
This is, in principle, a good thing, given that preset
matching/application shouldn't be dependent on how an area is
technically modelled . Alas the actually
Wasn't POSM supposed to solve this problem? :-)
Sorry for digressing.
In any case JOSM can already render "raw" OSM data, so supporting one of
the rendering/routing data formats would seem to be unnecessary. You
really only need to be able to apply a map style that is similar to a
conventional
And another data point: the implementation in Vespucci does not sort by
id (not only in theory, the output is really not ordered, which doesn't
cause issues with JOSM).
Or put differently: if that becomes a requirement, it would be a good
idea to versionize the format (which naturally wouldn't
I semi-manually generated a list of presets (using taginfos project
documentation) that "only" iD has, compared to vespucci. While the
vespucci - JOSM presets have diverged somewhat, the list may still be of
interest for this group.
https://github.com/simonpoole/beautified-JOSM-preset/issues/27
It is still a bit work in progress, will open a ticket once things are a
bit cleaned up.
Am 22.08.2017 um 19:17 schrieb Vincent Privat:
> Nice, could you please create a ticket for component "internal
> preset"? We'll sort out possible enhancements for JOSM.
>
> 2017-08-22
Florian
Why aren't you running the project in the OpenStreetMap organisation? If
you have no licensing concerns, it would be nice if we could all share
translations, taking load off translators and making things more
consistent over multiple projects.
Simon
Am 16.01.2018 um 12:18 schrieb
Well we would only want translations that are essentially rights free,
this is not a philosophical question, just a practical matter, as the
real benefit (outside of exposure to a larger group of translators) is
access to large amount of pre-translated expressions.
But if that is OK, I can make
In any case, as I read it, the implication is that oracle simply doesn't
want to be involved, not that anything will be going away.
Simon
Am 08.03.2018 um 08:36 schrieb Frederik Ramm:
> Hi,
>
> On 08.03.2018 00:06, Vincent Privat wrote:
>> I'm not sure what it implies for the long-term
Sat, 3 Nov 2018, Simon Poole wrote:
>
>> The current default preset has 12'214 lines of which roughly 5'564 are
>> used for href attributes in the "link" element. I actually suspect that
>> the number of lines used for the href entries is increasing faster
The current default preset has 12'214 lines of which roughly 5'564 are
used for href attributes in the "link" element. I actually suspect that
the number of lines used for the href entries is increasing faster than
the actual preset content and it is only a matter of time before they
will
Am 02.06.2019 um 21:28 schrieb Simon Poole:
> ..
> The canonical solution would be to move to gradle as the underlying
> build system, which works for both, potentially with a little bit of
Naturally it works without an IDE too. so it would cover all three use
cases.
Simo
As a non-JOSM dev, but forced to use IntelliJ now and then, and somebody
who really doesn't particularly like Eclipse: IntelliJ sucks so badly
that it makes eclipse look like the pinnacle of UI design. Just try
using IntelliJ with less than perfect eyesight, that is just one aspect
of many.
The
ELI has a privacy url field, though I believe Vespucci is currently the
only editor that a) points this out, and b) makes the link accessible to
end users.
Simon
Am 14.02.2020 um 18:46 schrieb Greg Troxel:
> Frederik Ramm writes:
>
>> I can understand that if I load Ilya's geochat plugin it
Assuming you are using the "standard" rails port
https://github.com/openstreetmap/openstreetmap-website/blob/master/config/settings.yml
line 27, iirc this is returned by the capabilities API call.
Simon
Am 19.03.2020 um 07:43 schrieb Yantisa Akhadi:
> Hello Paul,
>
> Thanks for your reply! This
Am 17.08.2020 um 22:40 schrieb Stephan Knauss:
>
> Can you elaborate a bit more in what way you wish this to be more
> structured?
>
> It is there to list similar tags. Do you want to structure the level
> of "similarity"?
To avoid any misunderstandings this is not about individual tags, but
Some of the recent patches to JOSMs default preset have included
elements for what are essentially presets for "similar"
objects.
Example:
5211
5212
5213
5214
5215
5216
20 matches
Mail list logo
