Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Tom Hughes]

On 30/10/15 01:11, Yuri Astrakhan wrote:


At the State of the Map conference, some OSM developers were discussing
the possibility of  migrating osm.org  to the
vector-based backend. I would like to get some feedback on feasibility
and desirability of this effort.


Well I think everybody thinks it's desirable and will happen at some 
point now that there are various options starting to mature as far as 
underlying technology stacks go.


Really though it's up to the stylesheet team - they're the ones that are 
going to have to do a lot of work and only once we have a style would we 
need to consider what stack to run it on.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[OSM-dev] Release openstreetmap-carto v2.36.0

[Matthijs Melissen]

Dear all,

Today, v2.36.0 of the openstreetmap-carto stylesheet has been
released and rolled out to the openstreetmap.org servers. It might
still take a couple of days before all tiles show the new rendering.

Changes include:

* Major rewrite of road and railway rendering, as part of Mateusz
Konieczny's Google Summer of Code project. See
https://blog.openstreetmap.org/2015/10/30/openstreetmap-org-map-changing/
for more information.
* Added rendering of the following tags:
  - amenity=fountain
  - amenity=car_wash
  - historic=wayside_cross and man_made=cross
  - shop=bag
  - shop=outdoor
  - power=plant (labels)
* Changed rendering of the following objects:
  - Placenames (new algorithm for deciding what placenames to render
on low zoomlevels)
  - Road shields
  - Oneway arrows
  - Glaciers
  - Marina labels
  - Station labels
* Dropped rendering of the following tags:
  - amenity=car_sharing (not relevant for the general public)
  - shop=antique (use shop=antiques)
  - shop=betting (use shop=lottery or shop=bookmaker)
  - shop=delicatessen (use shop=deli)
  - shop=dive (use shop=scuba_diving)
  - shop=fish (use shop=seafood, shop=pet, shop=angling or amenity=fast_food)
  - shop=gambling (use shop=lottery, shop=bookmaker, or
leisure=adult_gaming_centre)
  - shop=insurance (use office=insurance)
  - shop=pharmacy (use office=pharmacy)
  - shop=bags (use shop=bag)
* Various other bug fixes and minor improvements.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v2.35.0...v2.36.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues.

-- Matthijs

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Release openstreetmap-carto v2.36.0

[Matthijs Melissen]

On 30 October 2015 at 22:01, Matthijs Melissen  wrote:
>   - shop=pharmacy (use office=pharmacy)

This should be amenity=pharmacy instead of office=pharmacy, of course.

-- Matthijs

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [josm-dev] JMapViewer 1.12 release to accompany JOSM 8964?

[Vincent Privat]

Done!

2015-10-30 11:48 GMT+01:00 Vincent Privat :

> Hi Sebastiaan,
> We were busy to fix a few critical issues in josm 8964 => the new tested
> is 8969.
> I'm releasing jmapviewer this afternoon, don't worry :)
> Vincent
> Le 30 oct. 2015 11:30 AM, "Sebastiaan Couwenberg"  a
> écrit :
>
>> With the new tested snapshot for JOSM I also expected the JMapViewer
>> 1.12 release with wiktorns recent tile chache changes.
>>
>> I see that there is no JMapViewer 1.12 release yet, can we expect that
>> soon?
>>
>> Kind Regards,
>>
>> Bas
>>
>> --
>>  GPG Key ID: 4096R/6750F10AE88D4AF1
>> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
>>
>> ___
>> josm-dev mailing list
>> josm-dev@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/josm-dev
>>
>
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Oleksiy Muzalyev]

I've heard from the OSM operations team's member at the conference that 
it is the question of the servers' infrastructure cost.


But if we have a vector-based map itself language selection, that we 
could just add tags /name:fr/ or /name: ru/ and have the OSM map of say 
New York in French or in Russian for tourists. Or map of Siberia in 
German also for tourists, Middle East in English, etc. without any 
additions cost on the server side. It is not that difficult to add such 
multi-language tags. There could be also the map in Basque, Catalan, 
Kurdish, Scots and other smaller (by number of speakers) languages 
without any additional cost and without a civil conflict.


I realize that mobile hardware is not enough advanced for that yet and 
vector-based technology is only in an development stage.


brgds
Oleksiy

On 30.10.2015 12:06, Maarten Deen wrote:

On 2015-10-30 11:53, Oleksiy Muzalyev wrote:
One of the advantages of the the vector-based map would be the 
multilingualism.


For instance at the moment the OSM map of the Middle East is basically
useless for me as I do not know the Arabic alphabet yet. But as far as
I understand and as I heard at the conference the vector-based map
would allow the choice of a language of the map itself.


I do not see how that can not be solved with png-based tiles. You only 
have to render the tiles.

The method for detecting which tileset/language to show is the same.

BTW: it is still not as simple as rendering "in a different language". 
Then you start rendering a map in English and see names like "Cologne" 
or "Brussels"  show up on the map.


Regards,
Maarten

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Maarten Deen]

On 2015-10-30 11:53, Oleksiy Muzalyev wrote:
One of the advantages of the the vector-based map would be the 
multilingualism.


For instance at the moment the OSM map of the Middle East is basically
useless for me as I do not know the Arabic alphabet yet. But as far as
I understand and as I heard at the conference the vector-based map
would allow the choice of a language of the map itself.


I do not see how that can not be solved with png-based tiles. You only 
have to render the tiles.

The method for detecting which tileset/language to show is the same.

BTW: it is still not as simple as rendering "in a different language". 
Then you start rendering a map in English and see names like "Cologne" 
or "Brussels"  show up on the map.


Regards,
Maarten

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Christoph Hormann]

On Friday 30 October 2015, Jochen Topf wrote:
>
> This is not a failure of the vector tile approach in general. It
> might be a problem of how the vector tiles are generated today, but
> not a general problem of the vector tile approach. A vector tile can
> contain any data that you need for rendering any kind of style. The
> question is how the data will get into that vector tile. Currently
> the tool chain that does this is not mature enough, I agree. It
> doesn't take into account different sources of data (needed for
> special maps) and doesn't do generalization well enough. But this is
> something we can and should work on.

We need to distinguish a number of different things here:

1. the idea of storing and transporting geometries in a tiled form in 
general
2. the concept of current vector tile stacks
3. the idea of processing geometry on a level that is not generally 
possible to do on the fly during rendering

I was exclusively talking about 2. here, in particular because in 
contrast to the classical non-vector-tile stacks theys are not suited 
to efficiently deal with the geometric complexity issues without 3.  As 
i have mentioned many times i think 3. is important and grossly 
neglected.  Vector tiles might bring an additional incentive to address 
this of course.

The one important thing speaking against tiled geometry storage and 
transport in general is handling of different map projections.  Any 
such system will require you to select one projection from the very 
beginning and you stay bound to it or need fully separate setups for 
every projection you want to offer.

-- 
Christoph Hormann
http://www.imagico.de/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Colin Smale]

 

Can't we have a multi-lingual map by overlaying a base tile with a
transparent text layer in the chosen language? We wouldn't *need* vector
tiles for that, just a bit more storage (bitmap-based text layers should
compress nicely) and clients which can handle the selection and display
of the extra layer, which is pretty commonplace these days anyway). 

--colin 

On 2015-10-30 12:29, Oleksiy Muzalyev wrote: 

> I've heard from the OSM operations team's member at the conference that it is 
> the question of the servers' infrastructure cost.
> 
> But if we have a vector-based map itself language selection, that we could 
> just add tags _name:fr_ or _name: ru_ and have the OSM map of say New York in 
> French or in Russian for tourists. Or map of Siberia in German also for 
> tourists, Middle East in English, etc. without any additions cost on the 
> server side. It is not that difficult to add such multi-language tags. There 
> could be also the map in Basque, Catalan, Kurdish, Scots and other smaller 
> (by number of speakers) languages without any additional cost and without a 
> civil conflict.
> 
> I realize that mobile hardware is not enough advanced for that yet and 
> vector-based technology is only in an development stage.
> 
> brgds
> Oleksiy
> 
> On 30.10.2015 12:06, Maarten Deen wrote: On 2015-10-30 11:53, Oleksiy 
> Muzalyev wrote: 
> One of the advantages of the the vector-based map would be the 
> multilingualism. 
> 
> For instance at the moment the OSM map of the Middle East is basically 
> useless for me as I do not know the Arabic alphabet yet. But as far as 
> I understand and as I heard at the conference the vector-based map 
> would allow the choice of a language of the map itself. 
> I do not see how that can not be solved with png-based tiles. You only have 
> to render the tiles. 
> The method for detecting which tileset/language to show is the same. 
> 
> BTW: it is still not as simple as rendering "in a different language". Then 
> you start rendering a map in English and see names like "Cologne" or 
> "Brussels"  show up on the map. 
> 
> Regards, 
> Maarten 
> 
> ___ 
> dev mailing list 
> dev@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/dev

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev ___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Christoph Hormann]

On Friday 30 October 2015, Martin Koppenhoefer wrote:
> >
> > - improved tile serving efficiency
> > - a larger bandwidth of style variations
> > - tighter contraints in basic styling decisions beyond what is
> > already imposed by the OSM data model
>
> some additional points that come into mind:
>
> [...]

Note these are issues with client side rendering, not with vector 
tiles - those are ultimately independent things.  That client side 
rendering is often not very efficient if you consider overall costs is 
a given.

Especially when serving different styles from the same infrastructure 
(as most vector tiles map providers do) there is certainly potential 
for energy saving by caching the vector representations on the server 
side.  If the way this is done with current vector tiles stacks is the 
most efficient approach for that is a different matter of course.

-- 
Christoph Hormann
http://www.imagico.de/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Daniel Koć]

W dniu 30.10.2015 11:10, Martin Koppenhoefer napisał(a):


- vector maps are consuming more energy to display (because have to be
calculated/rendered) -> problem on mobile devices, but also generally


Mobile applications like OsmAnd show that while it really is slower, 
it's still usable.


I would not like to "migrate" osm.org to anything - including vector 
tiles - right now. I would rather like to have vector playground to test 
it and draw some conclusions myself. Yet at this moment I'm not aware of 
such experimental service.


--
"The train is always on time / The trick is to be ready to put your bags 
down" [A. Cohen]


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Christoph Hormann]

On Friday 30 October 2015, Yuri Astrakhan wrote:
>
> Kartotherian , the
> Mapnik+Mapbox-based vector service has been implemented and
> trial-launched  at Wikipedia. The
> service itself is fairly stable, but the styles can use some
> improvements - both the sql->vtile
>  and
> vtile->image .
> Hopefully this work can be used as the basis for the osm.org style.
> Once the vtiles are ready, we can easily move to client side WebGL
> rendering.

From my perspective this, i.e. imposing a certain technological 
framework on designers based on technological considerations, is the 
wrong approach.  I wrote about this on my blog recently from a slightly 
different angle[1].  For a high quality style, design development has 
to mandate the technological framework, not the other way round.

If you look at design problems recently discussed in the osm-carto style 
development[2] you will see most of them have nothing to do with vector 
tiles, they would not be made any easier to address with such an 
approach.  On the other hand there are a multitude of things the 
current style handles fairly gracefully, especially the problem of 
reducing geometric complexity, that would be much harder to deal with 
in a vector tiles system[3].

In general it seems to me vector tiles are today often carried as some 
kind of religious mantra promising to be the solution of all problems 
while in reality they certainly are not.  It is better to look for and 
identify actual design problems and see what technological means are 
available to solve them.  So far use of vector tiles seem to primarily 
have lead to the following effects:

- improved tile serving efficiency
- a larger bandwidth of style variations
- tighter contraints in basic styling decisions beyond what is already 
imposed by the OSM data model

In short: from a design perspective vector tiles so far brought more 
variety in map styles but they ultimately all look very similar beyond 
superficial aspects.  Nearly all of the more unusual maps that 
currently exist are not vector tile based.

[1] http://blog.imagico.de/map-design-economics/
[2] https://github.com/gravitystorm/openstreetmap-carto
[3] For another example of where wikimedia maps fails miserably here 
see:
https://maps.wikimedia.org/#18/47.99579/7.85194
http://www.openstreetmap.org/#map=18/47.99579/7.85194

-- 
Christoph Hormann
http://www.imagico.de/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Oleksiy Muzalyev]

One of the advantages of the the vector-based map would be the 
multilingualism.


For instance at the moment the OSM map of the Middle East is basically 
useless for me as I do not know the Arabic alphabet yet. But as far as I 
understand and as I heard at the conference the vector-based map would 
allow the choice of a language of the map itself.


There are so many disputes about languages, so an ability to just select 
whatever language one wants makes it not just a new feature but speaking 
figuratively an advent of a new brave world.


brgds
Oleksiy




___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Martin Koppenhoefer]

2015-10-30 10:52 GMT+01:00 Christoph Hormann :

> So far use of vector tiles seem to primarily
> have lead to the following effects:
>
> - improved tile serving efficiency
> - a larger bandwidth of style variations
> - tighter contraints in basic styling decisions beyond what is already
> imposed by the OSM data model
>


some additional points that come into mind:

- vector maps are consuming more energy to display (because have to be
calculated/rendered) -> problem on mobile devices, but also generally a
problem because every client has to spend energy on calculating the "same"
image (admittedly depends how many different styles there are, and how many
people are looking at them until the underlying data changes), so globally
(i.e. wikipedia use and not some "niche" usecases) this means really a lot
of wasted energy.

- are likely slower to display (for the same reason), although this is
depending on different factors (e.g. if you have internet connection and
how fast it is (vector maps likely scale better for offline use), how
complex the style sheet is, etc.) -> generally vector maps require more
ressources, newer more capable client devices.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Jochen Topf]

On Fr, Okt 30, 2015 at 10:52:40 +0100, Christoph Hormann wrote:
> If you look at design problems recently discussed in the osm-carto style 
> development[2] you will see most of them have nothing to do with vector 
> tiles, they would not be made any easier to address with such an 
> approach.  On the other hand there are a multitude of things the 
> current style handles fairly gracefully, especially the problem of 
> reducing geometric complexity, that would be much harder to deal with 
> in a vector tiles system[3].

This is not a failure of the vector tile approach in general. It might be a
problem of how the vector tiles are generated today, but not a general
problem of the vector tile approach. A vector tile can contain any data
that you need for rendering any kind of style. The question is how the
data will get into that vector tile. Currently the tool chain that does
this is not mature enough, I agree. It doesn't take into account different
sources of data (needed for special maps) and doesn't do generalization
well enough. But this is something we can and should work on.

And one more thing: I suggest we start thinking about not one set of vector
tiles, but many. Each one can contain different data (from OSM or not) derived
in different ways. Vector tiles from different tile sets can then be merged
(either in an extra step before delivering to client, or during rendering).
This will give us enormous flexiblity and decouple different parts of the
tool chain to allow for easier experimentation.

As an example: Somebody can have a very specialized process for generalizing,
say, railway infrastructure for low zoom levels. This can then be combined with
the standard tiles for rendering specialized maps without requiring the
maker of the specialized map to have a full OSM tool chain working.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-351-31778688

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Simon Poole]

Am 30.10.2015 um 11:10 schrieb Martin Koppenhoefer:
>
> 2015-10-30 10:52 GMT+01:00 Christoph Hormann  >:
>
> So far use of vector tiles seem to primarily
> have lead to the following effects:
>
> - improved tile serving efficiency
> - a larger bandwidth of style variations
> - tighter contraints in basic styling decisions beyond what is already
> imposed by the OSM data model
>
>
>
> some additional points that come into mind:
>
> - vector maps are consuming more energy to display (because have to be
> calculated/rendered) -> problem on mobile devices, but also generally
> a problem because every client has to spend energy on calculating the
> "same" image (admittedly depends how many different styles there are,
> and how many people are looking at them until the underlying data
> changes), so globally (i.e. wikipedia use and not some "niche"
> usecases) this means really a lot of wasted energy.
>
> - are likely slower to display (for the same reason), although this is
> depending on different factors (e.g. if you have internet connection
> and how fast it is (vector maps likely scale better for offline use),
> how complex the style sheet is, etc.) -> generally vector maps require
> more ressources, newer more capable client devices.

I don't think anybody is contemplating moving completely away from
server-side tile rendering osm.org at this point in time,  using vector
tiles pre-rendering will likely simply be a further option.

I kind of half agree with Christoph, but I think the perspective that
the vector tiles are a complete replacement for a style specific
rendering database is likely simply wrong. So while vector tiles allow
to produce a group of related styles where you previously simply had
one, if you are doing something completely different you will not be
able to use the same tile set. Naturally, in a wide sense of the word,
there is likely a substantial amount of economic pressure to reuse what
is already there which might lead to really different styles becoming
rarer than they are now . Obviously Andy, Christoph, Richard et al know
a lot more about this than I do. 

Simon


signature.asc
Description: OpenPGP digital signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [josm-dev] JMapViewer 1.12 release to accompany JOSM 8964?

[Sebastiaan Couwenberg]

On 30-10-15 12:22, Vincent Privat wrote:
> Done!

Thanks!

The updated Debian packages will be available later today.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Stadin, Benjamin]

One such service would be MapBox [1] itself. And in my opinion
mapbox-gl-js would be a natural choice for the client part. MapBox is
doing a really good job, and this is getting really solid.

I wrote a tiny script to create a mapbox-gl-js package for own deployment
[2]. It doesn't do much useful at the moment, other than doing a basic
host config of the build and generating and packaging some of the required
assets. No custom style integration, and no font generation (I wanted to
add this to the script, so they'd be generated from freetype fonts [3]
using fontnik [4]).

~Ben

[1] https://www.mapbox.com/mapbox-gl-js/examples/
[2] https://github.com/benstadin/mapbox-gl-js-packager
[3] https://fedorahosted.org/liberation-fonts/
[4] https://github.com/mapbox/node-fontnik



Am 30.10.15 12:50 schrieb "Daniel Koć" unter :

>W dniu 30.10.2015 11:10, Martin Koppenhoefer napisał(a):
>
>> - vector maps are consuming more energy to display (because have to be
>> calculated/rendered) -> problem on mobile devices, but also generally
>
>Mobile applications like OsmAnd show that while it really is slower,
>it's still usable.
>
>I would not like to "migrate" osm.org to anything - including vector
>tiles - right now. I would rather like to have vector playground to test
>it and draw some conclusions myself. Yet at this moment I'm not aware of
>such experimental service.
>
>-- 
>"The train is always on time / The trick is to be ready to put your bags
>down" [A. Cohen]
>
>___
>dev mailing list
>dev@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/dev


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Simon Poole]

Am 30.10.2015 um 13:31 schrieb Maarten Deen:
>
> So you have to have some kind of mechanisme to decide when to show
> name:en (which I want to see for e.g. Afghanistan) and when to show name.
>
That is simple, we live with some people not being completely happy :-) *

Seriously the whole point is exposing questionable tag values then they
get fixed, so if Gravelines has name:nl=Grevelingen tagged but in
reality that should be old_name:nl=Grevelingen the best way to get it
fixed is to show the wrong value on the map.

Simon

* even an imperfect language specific map is likely going to make more
people happy than now




signature.asc
Description: OpenPGP digital signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Maarten Deen]

On 2015-10-30 12:29, Oleksiy Muzalyev wrote:


But if we have a vector-based map itself language selection, that we
could just add tags _name:fr_ or _name: ru_ and have the OSM map of
say New York in French or in Russian for tourists. Or map of Siberia
in German also for tourists, Middle East in English, etc. without any
additions cost on the server side. It is not that difficult to add
such multi-language tags. There could be also the map in Basque,
Catalan, Kurdish, Scots and other smaller (by number of speakers)
languages without any additional cost and without a civil conflict.


Again, that does not work. I am Dutch. There are a lot of name:nl tags 
in the database that really are too obscure to put on a map.
There is a place "Grevelingen" which we associate with a lake in the 
southwest of the country. But it is also the old dutch name for the 
french town of Gravelines which nobody uses.
But similarly, I don't want to see the name:en tag for of cities 
because, as in my example, I will see Cologne or Brussels or Hook of 
Holland, which are all not what I want to see.
So you have to have some kind of mechanisme to decide when to show 
name:en (which I want to see for e.g. Afghanistan) and when to show 
name.




I realize that mobile hardware is not enough advanced for that yet and
vector-based technology is only in an development stage.

brgds
Oleksiy

On 30.10.2015 12:06, Maarten Deen wrote:


On 2015-10-30 11:53, Oleksiy Muzalyev wrote:


One of the advantages of the the vector-based map would be the
multilingualism.

For instance at the moment the OSM map of the Middle East is
basically
useless for me as I do not know the Arabic alphabet yet. But as
far as
I understand and as I heard at the conference the vector-based map

would allow the choice of a language of the map itself.


I do not see how that can not be solved with png-based tiles. You
only have to render the tiles.
The method for detecting which tileset/language to show is the same.


BTW: it is still not as simple as rendering "in a different
language". Then you start rendering a map in English and see names
like "Cologne" or "Brussels"  show up on the map.

Regards,
Maarten

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev



___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Oleksiy Muzalyev]

In Dutch, in English and other languages based on the Latin alphabet 
/Afghanistan/ is spelled about the same. But for example in Greek it is: 
/Αφγανιστάν/, in Ukrainian: /Афганістан/, in Kazakh: /Ауғанстан/, etc. 
Even though people study foreign languages in school, the absolute 
majority speak, read and write realistically only in a native language. 
The name of the country /Afghanistan /even in Latin letters is not 
understandable to a lot of people.


Certainly, there is a lot of imperfection in a language tagging yet, as 
it has not been that important. But if there is a robust comprehensive 
multilingual map solution similar to say the Gettext for text websites, 
then mappers will pay more attention to this type of tags.


brgds
Oleksiy

On 30.10.2015 13:31, Maarten Deen wrote:
So you have to have some kind of mechanisme to decide when to show 
name:en (which I want to see for e.g. Afghanistan) and when to show name.


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[josm-dev] JOSM feedback on Java 7,8,9, including Jigsaw EA

[Vincent Privat]

Hi,
Following the recent inclusion of JOSM to the Quality Outreach list by the
Adoption Group, we have compiled every single Java issue we have
encountered, and reported when it was new, for the latest versions of Java,
on a single page:

https://josm.openstreetmap.de/wiki/JavaBugs

We will use this page to coordinate our communication efforts with you. Is
it possible to add a link to it in the last column of the Quality Outreach
table?

The list currently contains 29 unresolved items and 18 resolved ones.

I won't go through all of them in this e-mail. Ideally we'd like to see all
of them fixed in a future Java release but I will only focus on the most
important ones.

Concerning Jigsaw:
- We have reported 3 bugs. All made it to the public JIRA: 8138878,
8140477, 8140481. The second one is a bit problematic for our tests as it
basically kills our Jenkins instance. I see the two other ones are
understood/in progress. We will do more tests after we resolve the hanging
problem.
- We'd like to know if it can be expected to see the
package sun.security.x509 become a public JDK API, for example in
javax.security.cert? We currently use it to generate a self-signed
certificate in order to create a local https server. That's our only use of
private JDK API.

Concerning Valhalla:
- I see some discussions about building the JDK with project Valhalla. Are
you going to provide public Early Access builds like project Jigsaw?

Concerning the JIRA database:
- Is it possible to add the label "josm-found" to
issues 8140481, 8139659, 8034224, 7158257, 7194099 ?
- Some issues didn't make it to the public JIRA and remained in the private
bug database. Can we please have more information on them (why have they
apparently been rejected)? The incident numbers
are JI-9009025, JI-9010791, JI-9009449, JI-9008003.
- Is it expected to allow external people to have the possibility to
subscribe to JDK issues?

Concerning our incoming migration from Java 7 to Java 8:
- I am concerned about three issues in Java2D/AWT on Linux. We have several
duplicate bug reports for them: 6322854, 7172749, 8098530. Can we hope for
a fix in a future update of Java 8?

Finally:
- We had a terrible experience when trying to report a bug against JAXP. We
detected a severe data corruption problem in StaX when dealing with Unicode
SMP characters, so we reported it, including a sample Java program 100%
reproducible, in January 2013 (JAXP-76 on java.net JIRA). As no activity
was visible on this JIRA instance, we tried to use the standard Java bug
report, three times, without success, with incident numbers 2431783
(2013-01-23), 2627098 (2013-10-28) and 9048481 (2014-11-28), without any
answer. On 2014, November 29th we discovered by chance that the bug had
finally been detected and fixed internally, as JDK-8058175 (created and
resolved in September 2014). We reported back to the public JAXP JIRA
instance, again without any answer. 6 months later we finally got the
ironic and laconic answer "Please report issues to the OpenJDK Bug System",
which was exactly was we were trying to do for 2 years! Can you please tell
us why our bug reports were all silently ignored while the bug was real,
and if is it still worth reporting bugs against JAXP? Thankfully we had far
better experiences with other components of the JDK.
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

[josm-dev] JMapViewer 1.12 release to accompany JOSM 8964?

[Sebastiaan Couwenberg]

With the new tested snapshot for JOSM I also expected the JMapViewer
1.12 release with wiktorns recent tile chache changes.

I see that there is no JMapViewer 1.12 release yet, can we expect that soon?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev