Re: [OSM-talk] admin_level 4 rendering

[Paul Norman]

Subarea members are a pain and duplicate geographic information, but I don’t
think they cause any performance issues, largely because all the relevant
tools ignore them.

 

From: Pierre Béland [mailto:pierz...@yahoo.fr] 
Sent: Monday, April 07, 2014 12:29 PM
To: Felix Delattre
Cc: Talk Openstreetmap
Subject: Re: [OSM-talk] admin_level 4 rendering

 

In the relation for Nicaragua (id=287666), there are objects with role
subarea.  For example, addition of subarea role for Chontales is redundant
with Relation  Chontales (id=2194866). I dont know if this would fix the
problem, but you could remove the redundant subarea members from the
Nicaragua relation.  Developpers that know how relations are rendered could
tell what is the impact of redundant references adding subarea elements to
the main relation.

 

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

Re: [OSM-talk] admin_level 4 rendering

[Felix Delattre]

I just added this today because in the local talk list (talk-ni) a
friendly person pointed me to the relation defining Florida 
(http://www.openstreetmap.org/relation/162050) which is a subarea of USA
http://www.openstreetmap.org/relation/148838

It made sense to me to add all the states/departamentos to the country's
relation, so I did it. But this should be irrelevant to the rendering as
the states of USA and the provinces of Costa Rica are getting rendered
properly, no matter if they are as subarea defined in a parent relation
(like it is the case in USA) or not (in Costa Rica).

On 04/07/2014 01:29 PM, Pierre Béland wrote:
> In the relation for Nicaragua (id=287666), there are objects with role
> subarea.  For example, addition of subarea role for Chontales is
> redundant with Relation  Chontales (id=2194866). I dont know if this
> would fix the problem, but you could remove the redundant subarea
> members from the Nicaragua relation.  Developpers that know how
> relations are rendered could tell what is the impact of redundant
> references adding subarea elements to the main relation.
>  
> Pierre
>
> 
> *De :* Felix Delattre 
> *À :*
> *Cc :* Talk Openstreetmap 
> *Envoyé le :* Lundi 7 avril 2014 20h42
> *Objet :* Re: [OSM-talk] admin_level 4 rendering
>
> Thank you, Clifford.
>
> I hope I could fix those, by rechecking all the tagging and roles
> ("outer" especially) in the relations. I think this could have been
> the reason. Nevertheless this phenonema of not rendering the label of
> the admin_level=4 regions is happening with all regions/departamentos
> in Nicaragua. Also the ones which are not throwing an error by the OSM
> Inspector [1] Please compare with the relations which are subareas of
> the county's relation [2].
> I further added a label to one of the regions' relation [3], using the
> short name for testing purposes, and placed it where no much other
> stuff is around.
>
> Marking the tiles, close to this label node, as "/dirty" to refresh
> them, would not render the region's label... :(
>
>
> [1]
> http://tools.geofabrik.de/osmi/?view=multipolygon&lon=-85.04810&lat=12.23695&zoom=8&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes
> [2] http://www.openstreetmap.org/relation/287666
> 
> [3] http://www.openstreetmap.org/relation/2195081#map=8/11.921/-83.589
>
> On 04/07/2014 11:14 AM, Clifford Snow wrote:
>>
>> On Mon, Apr 7, 2014 at 9:48 AM, Felix Delattre > > wrote:
>>
>> I was going over the "departmentos" (admin_level=4) in Nicaragua
>> yesterday. And it does not explain to me why the names of them not
>> getting rendered in Mapnik. Please compare:
>>
>>  * Province (admin_level=4) in Costa Rica:
>> http://www.openstreetmap.org/relation/3222919#map=8/10.747/-85.051
>> (label "Guanacaste")
>>  * Departamentos (admin_level=4) in Nicaragua
>> http://www.openstreetmap.org/relation/2194866#map=8/11.792/-85.122 (no
>> label "Chontales")
>>
>>
>> I noticed in OSM Inspector an error on the Chontales multipolygon:  
>> layer:   ring_not_closed_hull
>> rel_id:  2194866
>> lastchange:  2014-03-12T04:13:04Z
>> errmsg:  ring_not_closed
>> area:0.78
>> tags:admin_level=4
>> boundary=administrative
>> name=Chontales
>>
>>
>> Fix the errors to see if that fixes the rendering problem.
>>
>> Clifford
>>
>> -- 
>> @osm_seattle
>> osm_seattle.snowandsnow.us 
>> OpenStreetMap: Maps with a human touch
>
>
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk
>
>

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

Re: [OSM-talk] admin_level 4 rendering

[Pierre Béland]

In the relation for Nicaragua (id=287666), there are objects with role subarea. 
 For example, addition of subarea role for Chontales is redundant with Relation 
 Chontales (id=2194866). I dont know if this would fix the problem, but you 
could remove the redundant subarea members from the Nicaragua relation.  
Developpers that know how relations are rendered could tell what is the impact 
of redundant references adding subarea elements to the main relation.
 
Pierre 




 De : Felix Delattre 
À : 
Cc : Talk Openstreetmap  
Envoyé le : Lundi 7 avril 2014 20h42
Objet : Re: [OSM-talk] admin_level 4 rendering
 


Thank you, Clifford.

I hope I could fix those, by rechecking all the tagging and roles
  ("outer" especially) in the relations. I think this could have
  been the reason. Nevertheless this phenonema of not rendering the
  label of the admin_level=4 regions is happening with all
  regions/departamentos in Nicaragua. Also the ones which are not
  throwing an error by the OSM Inspector [1] Please compare with the
  relations which are subareas of the county's relation [2].
I further added a label to one of the regions' relation [3], using
  the short name for testing purposes, and placed it where no much
  other stuff is around.

Marking the tiles, close to this label node, as "/dirty" to
  refresh them, would not render the region's label... :(


[1] 
http://tools.geofabrik.de/osmi/?view=multipolygon&lon=-85.04810&lat=12.23695&zoom=8&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes
[2] http://www.openstreetmap.org/relation/287666
[3] http://www.openstreetmap.org/relation/2195081#map=8/11.921/-83.589

On 04/07/2014 11:14 AM, Clifford Snow wrote:


>
>On Mon, Apr 7, 2014 at 9:48 AM, Felix Delattre  wrote:
>
>I was going over the "departmentos" (admin_level=4) in Nicaragua
>>yesterday. And it does not explain to me why the names
of them not
>>getting rendered in Mapnik. Please compare:
>>
>> * Province (admin_level=4) in Costa Rica:
>>http://www.openstreetmap.org/relation/3222919#map=8/10.747/-85.051
>>(label "Guanacaste")
>> * Departamentos (admin_level=4) in Nicaragua
>>http://www.openstreetmap.org/relation/2194866#map=8/11.792/-85.122 (no
>>label "Chontales") 
>I noticed in OSM Inspector an error on the Chontales
  multipolygon:  
>layer:ring_not_closed_hull 
>rel_id:2194866 
>lastchange:2014-03-12T04:13:04Z 
>errmsg:ring_not_closed 
>area:0.78 
>tags:admin_level=4
>boundary=administrative
>name=Chontales
>
> 
>Fix the errors to see if that fixes the rendering problem.
>
>
>Clifford
>
>
>
-- 
>
>@osm_seattle
>
>osm_seattle.snowandsnow.us
>OpenStreetMap: Maps with a human touch


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

Re: [OSM-talk] admin_level 4 rendering

[Felix Delattre]

Thank you, Clifford.

I hope I could fix those, by rechecking all the tagging and roles
("outer" especially) in the relations. I think this could have been the
reason. Nevertheless this phenonema of not rendering the label of the
admin_level=4 regions is happening with all regions/departamentos in
Nicaragua. Also the ones which are not throwing an error by the OSM
Inspector [1] Please compare with the relations which are subareas of
the county's relation [2].
I further added a label to one of the regions' relation [3], using the
short name for testing purposes, and placed it where no much other stuff
is around.

Marking the tiles, close to this label node, as "/dirty" to refresh
them, would not render the region's label... :(


[1]
http://tools.geofabrik.de/osmi/?view=multipolygon&lon=-85.04810&lat=12.23695&zoom=8&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes
[2] http://www.openstreetmap.org/relation/287666
[3] http://www.openstreetmap.org/relation/2195081#map=8/11.921/-83.589

On 04/07/2014 11:14 AM, Clifford Snow wrote:
>
> On Mon, Apr 7, 2014 at 9:48 AM, Felix Delattre  > wrote:
>
> I was going over the "departmentos" (admin_level=4) in Nicaragua
> yesterday. And it does not explain to me why the names of them not
> getting rendered in Mapnik. Please compare:
>
>  * Province (admin_level=4) in Costa Rica:
> http://www.openstreetmap.org/relation/3222919#map=8/10.747/-85.051
> (label "Guanacaste")
>  * Departamentos (admin_level=4) in Nicaragua
> http://www.openstreetmap.org/relation/2194866#map=8/11.792/-85.122 (no
> label "Chontales")
>
>
> I noticed in OSM Inspector an error on the Chontales multipolygon:  
> layer:ring_not_closed_hull
> rel_id:   2194866
> lastchange:   2014-03-12T04:13:04Z
> errmsg:   ring_not_closed
> area: 0.78
> tags: admin_level=4
> boundary=administrative
> name=Chontales
>
>
> Fix the errors to see if that fixes the rendering problem.
>
> Clifford
>
> -- 
> @osm_seattle
> osm_seattle.snowandsnow.us 
> OpenStreetMap: Maps with a human touch

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

Re: [OSM-talk] admin_level 4 rendering

[Clifford Snow]

On Mon, Apr 7, 2014 at 9:48 AM, Felix Delattre  wrote:

> I was going over the "departmentos" (admin_level=4) in Nicaragua
> yesterday. And it does not explain to me why the names of them not
> getting rendered in Mapnik. Please compare:
>
>  * Province (admin_level=4) in Costa Rica:
> http://www.openstreetmap.org/relation/3222919#map=8/10.747/-85.051
> (label "Guanacaste")
>  * Departamentos (admin_level=4) in Nicaragua
> http://www.openstreetmap.org/relation/2194866#map=8/11.792/-85.122 (no
> label "Chontales")
>

I noticed in OSM Inspector an error on the Chontales multipolygon:
layer:ring_not_closed_hullrel_id:2194866 lastchange:2014-03-12T04:13:04Z
errmsg:ring_not_closedarea:0.78 tags:admin_level=4
boundary=administrative
name=Chontales


Fix the errors to see if that fixes the rendering problem.

Clifford

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Info on SOTM (WAS: No new information on the SOTM since January 2014)

[Rob Nickerson]

Hi Gonzalo, Henk,

Thanks for the update. Having helped organise last year I had no doubt that
SOTM 2014 would be going ahead - the OSMF, Henk and the SOTM Working Group
are all behind it.

Let me know if you need help with anything (announcements, blogging,
tweeting or something that I can do from here in the UK). I'll send you
some tips and the feedback results from last year - although I expect Henk
may have done that already.

Best wishes,
Rob
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] admin_level 4 rendering

[Felix Delattre]

I was going over the "departmentos" (admin_level=4) in Nicaragua
yesterday. And it does not explain to me why the names of them not
getting rendered in Mapnik. Please compare:

 * Province (admin_level=4) in Costa Rica:
http://www.openstreetmap.org/relation/3222919#map=8/10.747/-85.051
(label "Guanacaste")
 * Departamentos (admin_level=4) in Nicaragua
http://www.openstreetmap.org/relation/2194866#map=8/11.792/-85.122 (no
label "Chontales") or
http://www.openstreetmap.org/relation/2195081#map=8/12.536/-83.798 (no
label).

No "departamento"/state's label is getting rendered but both have the
same tagging on their relations. The relations aren't new and no
rendering happens in the default mapnik style neither in the
humanitarian: http://www.openstreetmap.org/#map=8/11.378/-85.045&layers=H

I would appreciate some help. This would make the map much more
comfortable and complete.

Kind regards,
Felix

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

Re: [OSM-talk] No new information on the SOTM since January 2014

[Gonzalo Gabriel Pérez]

Hello everyone.

I've read previous messages of this thread and as coordinator of the local
organizing committee i can understand your concern about SotM status.

This is the first event that we organize as a community in Argentina,
because previous meetings have taken place in more informal context. In
South America we don't have the same number of communities and members that
exist today in Europe or in the United States, we still much to do, learn
and grow and we're convinced that the realization of an event like State of
the Map will be one of the first steps to build a community through the
common work.

Because the above, is reasonable to expect that the effort is greater
because it not only involves the organization of a conference, but also
require to build a working group on the basis of a community that never
worked for an aim like that until today.

We've been talking with Henk about doing the conference here since last
year, even before Birmingham was announced as host, but we understood that
it was necessary to prepare well for this purpose, with more time than it
would take elsewhere. IIn fact, most of those that are members of the local
organizing committee joined when Buenos Aires was announced as the next
host.
For our luck, Henk has fully cooperated with us from the begining so we are
grateful.

Currently our committee consists of 18 people, and we are doing our best to
make a conference that include all the necessary with a minimal budget,
because our aim is to contribute to the objectives of the Foundation even
economically.

We've not yet announced prices, location and other details because since
last year Buenos Aires has many scheduled activities which makes it
difficult to achieve the necessary with a minimum cost or even free.

At the moment we have the logo, which has already been uploaded to the
SotM's official twitter account and currently we're working on the website
development.

I know that some of you have organized previous SOTM so your experience may
be very useful. We are open to all contributions, suggestions and inquiries
you may have.

Hoping to have cleared some of their concerns, I greet you.
See you soon,

Gonzalo G. Perez
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-legal-talk] Community Guidelines needs your review

[Michael Collinson]

I have now almost finished a major revamp of the Community Guideline 
pages at 
https://wiki.openstreetmap.org/wiki/Open_Data_License/Community_Guidelines. 
I now ask for a few eyeballs to review the pages so that they represent 
a community consensus rather than what Michael Collinson thinks.


I  revamped the format of each guideline for clarity and harmony. The 
actual guideline itself is now confined to a single section "The Guideline".


I added wording to the "Trivial Transformation" guideline from 2012 
email on this mailing list.


I added a new guideline "Regional Cuts" for something we have allowed 
but never formally codified.


I added a new guideline "Horizontal Layers". We believe legally ODbL is 
actually pretty clear on this, but it is difficult to understand for 
practical use of geodata.


My key questions to you are:

1) The following guidelines have existed for a long time with no 
significant change or challenge,  "the age test". Do you have any 
objections to bumping them to the next step, formal endorsement by the 
Foundation?


o Substantial
o Produced Work
o Trivial Transformations (strictly speaking the text is new on the wiki 
but has been around since 2012 on this list)


2) Do these new guidelines seem reasonable to you?

o Regional Cuts
o Horizontal layers

3) There are two new open issues in the "Regional Cuts" 
https://wiki.openstreetmap.org/wiki/Open_Data_License/Regional_Cuts_-_Guideline 
. Do you have any opinion?  I will write a separate posting about them 
to make it easier.


4) Can you think of better, more obvious, names for any of the guidelines?

Mike

Michael Collinson
License Working Group







___
legal-talk mailing list
legal-t...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

[OSM-talk] Added more tickets for State of the Map US - squeeze in

[Alex Barth]

This weekend, State of the Map US sold out at almost 500 tickets. Over the
weekend we crunched numbers and added 30 more, we have also set up a
waiting list. Find all details here on our blog post:

http://openstreetmap.us/2014/04/sotmus-more-tickets/

If you don't have a ticket yet, move fast on getting one, those 30 are
going fast.

Looking forward to seeing you in DC.

Alex

-- 
Alex Barth
Secretary
OpenStreetMap United States Inc.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSRM-talk] mix kilometers and speed

[didier2020]

sorry for my poor english , the data in my example may be false ...
it's just to add différents amont which are not distance or time
like l/km, highway with fee=yes 
is this possible or already integrated ?

Le lundi 07 avril 2014 à 13:44 +0200, Florian Lohoff a écrit : 
> On Mon, Apr 07, 2014 at 11:06:51AM +0200, didier2020 wrote:
> > hi,
> > 
> > i wonder if osrm can mix kilometers and speed to calculate a route
> > 
> > exemple: 
> > my car : 5l/100 km with 1l = 1.5 € => 0.075€ for one kilometer
> > me : my time can be arround 16€/h
> 
> But this is not true for todays cars. Its consumption per km and
> travel speed. Yes - with the current downsizing of motors you get
> much lower fuel consumption on partial load e.g. the citys. But
> driving on the motorway you'll consume the same amount of fuel
> than having a 6 cylinder 3,5l engine. So its not fuel per time
> but fuel per km and road type.
> 
> > so for a trip of 50 km, and 20 minutes 
> > => (50*0.075) + (20/60*16) = 3.75 + 5.33 = 9.08€
> 
> Flo



___
OSRM-talk mailing list
osrm-t...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSM-talk] State Of The Map France starting tomorrow in Paris

[Christian Quest]

streaming is currently under encoding... first video available will be in
english about addresses in Denmark.

FYI, we had 230 attendees over the 3 days (to compare to last year 50
attendees).


2014-04-05 9:47 GMT+02:00 Sylvain Maillard :

> SOTM-FR is live on http://numaparis.ubicast.tv/lives/numa-r4-event/
> webcast will be available ...
>
> programm (in french) : http://openstreetmap.fr/sotmfr2014/programme
>
>
>
> Sylvain
>
>
>
> 2014-04-03 15:01 GMT+02:00 Rob Nickerson :
>>
>>>
>>> Is there any live videos / webcasting for those folks who couldn't
>>> attend?
>>>
>>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>


-- 
Christian Quest - OpenStreetMap France
Conférence "State Of The Map" France du 4 au 6 avril à
Paris
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] ReMAPTCHA Demo BETA 0.2 online! (Was: Hate captchas!!!!)

[Stefan Keller]

Hi,

We slightly updated http://remaptcha.herokuapp.com/ : It now validates the
second control word (nearby the flag) better.

BUT now, we have another variant #2 which has two steps:
http://remaptcha2.herokuapp.com/
A variant means to me that's another possible solution (i.e. it's not
Version 2).

LG, Stefan



2014-04-05 12:18 GMT+02:00 Stefan Keller :

> Hi,
>
> We've slightly updated ReMAPTCHA plugin.
>
> -S.
>
> [1] http://remaptcha.herokuapp.com/
>
>
>
>
> 2014-03-31 18:47 GMT+02:00 moltonel 3x Combo :
>
> On 31/03/2014, Stefan Keller  wrote:
>> > The scrambling of the Control Word" is as intense as other Captchas but
>> > it's only 5-6 chars (instead of 10 or more).
>>
>> Hum, taking another look, it does seem more scrambled than I remember.
>> But when I first checked, there was only text over the map, not over
>> the imagery, so you changed stuff :p
>>
>> It's better, but I still feel it's not as scrambled as the typical
>> ReCAPTCHA; for example it doesn't have anything overlaying it.
>>
>> > We can afford this because an OCR needs to find first the boundaries of
>> the
>> > word - and that's more difficult with labels on a map.
>>
>> One major flaw with displaying the text on both layers (rendered and
>> satellite) is that you can  substract one image from the other to be
>> left with just the text without noise.
>>
>> Map labels are rare enough in the examples I saw. They might also be
>> easyly filtered out as being non-scrambled and using known typefaces.
>>
>> And if we get an area with many labels that somehow confuse a bot but
>> not a user, we're back to the "got a few words, try to give
>> combinations at random" problem.
>>
>> > You have to realize that the other word has to be written just to
>> indicate
>> > if there is a path - else you can ommit it.
>>
>> Yes.
>>
>> > The fact that there is a path is unknown to our system.
>>
>> I don't understand that part. You've created the chalenges, so you
>> must know the answer ?
>>
>> > So in your estimation, humans always succeded when only typing the
>> "Control
>> > Word".
>> > That (human) trick and not knowing the correct answer for the "Control
>> > Word" applies to all reCAPTCHAs.
>> > Bots need first to find 1. which one is the Control Word (including
>> > boundary) and then 2. to try OCR.
>>
>> Part of my point is that the bot doesn't need to distinguish the
>> control word from the other word (assuming it OCRed the words
>> correctly, see above). It has a 33% chance of getting it right
>> randomly, which is fine. A 10% overall success rate is not an issue
>> for a bot (but would be for a human).
>>
>> >> Please drop the "scrambled text" idea altogether. And make solving a
>> >> CAPTCHA a fun activity in the process.
>> >
>> > Feedback so far was, that it's at least more fun than typing 15
>> characters
>> > and helping G* instead of OSM.
>>
>> That's my feedback too :) Note that I wouldn't be commenting if I
>> thought the work didn't have merit :p
>>
>> But I'm afraid that the fun will quickly disapear, because we still
>> have to squint and type, and because you'll notice that you need to
>> raise the scrambling-related difficulty because bots still get thru.
>>
>> >> ...A "click features on the
>> >> satellite imagery" task is one way to do it, but I'm sure there are
>> >> others.
>> >
>> > This seems like a good idea and I'm open to collect those.
>>
>> I hope you'll explore the idea, so.
>>
>> There have been plenty of other attempts with image-based no-typing
>> CAPTCHAs (search those terms), but I think that they suffered from the
>> high cost of getting tagged source material. An OSM-backed satellite
>> imagery CAPTCHA would have a huge amount of source material readily
>> available.
>>
>> > Unfortunately nobody came up until now with one, which fulfilled the
>> > properties of a reCAPTCHA, i.e. fast and easy to understand challenge by
>> > humans.
>>
>> I guess it's the usual problem of plenty of people having their idea
>> about a feature, but it takes one person to actually go and do the
>> work before they reallize that they had different features in mind, or
>> that it was a bad idea... Thanks for working on that :)
>>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk