date:20130721

With the arrival of a 'new' set of controls, and the discussion on front page, I 
feel that it IS necessary to open this discussion a little wider. Having been 
using the new interface on mobile devices I find it much less usable than the 
older set-up. But that is not to say that the old one was actually usable! There 
is a need for a different map interface that works better with mobile devices. 
Even the routing demos have mixed results on tablets and mobile phones. I've 
been working on my own 'front end' simply to provide one that I can tailor for 
the devices I am using. The old N900 used to work well, but the newer devices 
are difficult to use 'on the go'. As an example, the old TomTom sat nav was easy 
to use while driving, but the current replacements I've tried to use with the 
Galaxy4 can be dangerous at times as they wander off doing their own thing, and 
you have to stop to get back to a state where you can continue following the route.


It's obvious that the new map interface is not designed for mobile devices, so 
where should we discuss that development and how it would fit in with an 
improved front end. It's not just a matter of directing to 'a map' but more 
important is directing to safe options for those of us who ARE using the tools 
every day. The current options are both difficult to find, and have clear 
information on how safe they are when using them live! Disclaimers of accepting 
no responsibility may cover any legal liability, but essentially say 'here is a 
tool - but you should never use it!'


And discussion on a more open platform would also be appreciated rather than on 
development platforms that we do not subscribe to because we use different 
development tools!


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] New technology ...

Hey Lester,

I agree entirely - thus far we aren't focusing on the mobile version of the
site. It's never been very polished, and recent changes aren't focused on
improving it significantly.

As far as why, it's pretty simple - changes to the site are extremely
time-intensive because of its myriad uses and the necessity of having a
community process. That is, we've needed to focus on specific parts of the
site because, even if we agree that many things need to be done, we only
have enough designers  developers to implement one or two things a month.

I think there are two solid ways forward here:

First, which is admittedly less likely, is if anyone wants to adopt the
task of maintaining, testing, and improving the mobile site, and pushing
those changes through.

Second, which is more doable but more likely to get over-communicated, is
for someone to write a simple page pointing to good mobile options. For
instance, users of GPS units should easily find out about Garmin extracts,
smartphone users should easily find editors that work on their phone or
apps that use OpenStreetMap data.

Independent OSM-based tools do a better job at the very specific use-cases
people have on mobile - whereas the website focuses strongly on one use
case, editing, and has no smartphone-compatible editors.

(To tackle the inevitable points of argument that follow that: yes, there
are things that do this, but we need to do better. No, there's no committee
to decide and yes the best way to do it is to do it, even if it's very
low-tech.)

Tom


On Sun, Jul 21, 2013 at 11:26 AM, Lester Caine les...@lsces.co.uk wrote:

 With the arrival of a 'new' set of controls, and the discussion on front
 page, I feel that it IS necessary to open this discussion a little wider.
 Having been using the new interface on mobile devices I find it much less
 usable than the older set-up. But that is not to say that the old one was
 actually usable! There is a need for a different map interface that works
 better with mobile devices. Even the routing demos have mixed results on
 tablets and mobile phones. I've been working on my own 'front end' simply
 to provide one that I can tailor for the devices I am using. The old N900
 used to work well, but the newer devices are difficult to use 'on the go'.
 As an example, the old TomTom sat nav was easy to use while driving, but
 the current replacements I've tried to use with the Galaxy4 can be
 dangerous at times as they wander off doing their own thing, and you have
 to stop to get back to a state where you can continue following the route.

 It's obvious that the new map interface is not designed for mobile
 devices, so where should we discuss that development and how it would fit
 in with an improved front end. It's not just a matter of directing to 'a
 map' but more important is directing to safe options for those of us who
 ARE using the tools every day. The current options are both difficult to
 find, and have clear information on how safe they are when using them live!
 Disclaimers of accepting no responsibility may cover any legal liability,
 but essentially say 'here is a tool - but you should never use it!'

 And discussion on a more open platform would also be appreciated rather
 than on development platforms that we do not subscribe to because we use
 different development tools!

 --
 Lester Caine - G8HFL
 -
 Contact - 
 http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk
 Rainbow Digital Media - 
 http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk

 __**_
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] New technology ...


Tom MacWright wrote:

Hey Lester,

I agree entirely - thus far we aren't focusing on the mobile version of the
site. It's never been very polished, and recent changes aren't focused on
improving it significantly.

As far as why, it's pretty simple - changes to the site are extremely
time-intensive because of its myriad uses and the necessity of having a
community process. That is, we've needed to focus on specific parts of the site
because, even if we agree that many things need to be done, we only have enough
designers  developers to implement one or two things a month.

And some of us are hampered by the choose of tools that was made previously!


I think there are two solid ways forward here:

First, which is admittedly less likely, is if anyone wants to adopt the task of
maintaining, testing, and improving the mobile site, and pushing those changes
through.
There are a few options as a good starting point, but your 'third' point is 
probably accurate here.



Second, which is more doable but more likely to get over-communicated, is for
someone to write a simple page pointing to good mobile options. For instance,
users of GPS units should easily find out about Garmin extracts, smartphone
users should easily find editors that work on their phone or apps that use
OpenStreetMap data.

http://lsces.co.uk/wiki/Mobile+Computing :)
But I'm getting bogged down by what does not work in each of the options and I 
don't have time to try the options that are missing. I need to switch from Locus 
to one of the other options just to establish where the identified safety issues 
actually arise from! If you can't trust a configuration then it's unusable, and 
that is part of the current problem.



Independent OSM-based tools do a better job at the very specific use-cases
people have on mobile - whereas the website focuses strongly on one use case,
editing, and has no smartphone-compatible editors.

Adding data via the tablet is easier than actually using it on the tablet ...


(To tackle the inevitable points of argument that follow that: yes, there are
things that do this, but we need to do better. No, there's no committee to
decide and yes the best way to do it is to do it, even if it's very low-tech.)
We need well documented user reports on the available tools rather than just 
'choose the option that works for you' ... I have yet to find a routing package 
that gives SAFE directions on UK motorways! This was the whole reason for my 
closer investigation.



Tom

On Sun, Jul 21, 2013 at 11:26 AM, Lester Caine les...@lsces.co.uk
mailto:les...@lsces.co.uk wrote:

With the arrival of a 'new' set of controls, and the discussion on front
page, I feel that it IS necessary to open this discussion a little wider.
Having been using the new interface on mobile devices I find it much less
usable than the older set-up. But that is not to say that the old one was
actually usable! There is a need for a different map interface that works
better with mobile devices. Even the routing demos have mixed results on
tablets and mobile phones. I've been working on my own 'front end' simply to
provide one that I can tailor for the devices I am using. The old N900 used
to work well, but the newer devices are difficult to use 'on the go'. As an
example, the old TomTom sat nav was easy to use while driving, but the
current replacements I've tried to use with the Galaxy4 can be dangerous at
times as they wander off doing their own thing, and you have to stop to get
back to a state where you can continue following the route.

It's obvious that the new map interface is not designed for mobile devices,
so where should we discuss that development and how it would fit in with an
improved front end. It's not just a matter of directing to 'a map' but more
important is directing to safe options for those of us who ARE using the
tools every day. The current options are both difficult to find, and have
clear information on how safe they are when using them live! Disclaimers of
accepting no responsibility may cover any legal liability, but essentially
say 'here is a tool - but you should never use it!'

And discussion on a more open platform would also be appreciated rather than
on development platforms that we do not subscribe to because we use
different development tools!


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] New technology ...

Hi Lester,

The most productive way to lead to better routing on OSM is to find 'bad'
routes, generate permalinks on OSRM or your favorite tool, and post bug
reports, including what the desired route would be and what's incorrect
about the incorrect route. For OSRM in particular the bug tracker is here:
https://github.com/DennisOSRM/Project-OSRM/issues and you can click
'Generate Link' on the testing instance: http://map.project-osrm.org/ in
order to send a specific route around.

Tom


On Sun, Jul 21, 2013 at 12:02 PM, Lester Caine les...@lsces.co.uk wrote:

 Tom MacWright wrote:

 Hey Lester,

 I agree entirely - thus far we aren't focusing on the mobile version of
 the
 site. It's never been very polished, and recent changes aren't focused on
 improving it significantly.

 As far as why, it's pretty simple - changes to the site are extremely
 time-intensive because of its myriad uses and the necessity of having a
 community process. That is, we've needed to focus on specific parts of
 the site
 because, even if we agree that many things need to be done, we only have
 enough
 designers  developers to implement one or two things a month.

 And some of us are hampered by the choose of tools that was made
 previously!


  I think there are two solid ways forward here:

 First, which is admittedly less likely, is if anyone wants to adopt the
 task of
 maintaining, testing, and improving the mobile site, and pushing those
 changes
 through.

 There are a few options as a good starting point, but your 'third' point
 is probably accurate here.


  Second, which is more doable but more likely to get over-communicated, is
 for
 someone to write a simple page pointing to good mobile options. For
 instance,
 users of GPS units should easily find out about Garmin extracts,
 smartphone
 users should easily find editors that work on their phone or apps that use
 OpenStreetMap data.

 http://lsces.co.uk/wiki/**Mobile+Computinghttp://lsces.co.uk/wiki/Mobile+Computing:)
 But I'm getting bogged down by what does not work in each of the options
 and I don't have time to try the options that are missing. I need to switch
 from Locus to one of the other options just to establish where the
 identified safety issues actually arise from! If you can't trust a
 configuration then it's unusable, and that is part of the current problem.


  Independent OSM-based tools do a better job at the very specific use-cases
 people have on mobile - whereas the website focuses strongly on one use
 case,
 editing, and has no smartphone-compatible editors.

 Adding data via the tablet is easier than actually using it on the tablet
 ...


  (To tackle the inevitable points of argument that follow that: yes, there
 are
 things that do this, but we need to do better. No, there's no committee to
 decide and yes the best way to do it is to do it, even if it's very
 low-tech.)

 We need well documented user reports on the available tools rather than
 just 'choose the option that works for you' ... I have yet to find a
 routing package that gives SAFE directions on UK motorways! This was the
 whole reason for my closer investigation.

  Tom

 On Sun, Jul 21, 2013 at 11:26 AM, Lester Caine les...@lsces.co.uk
 mailto:les...@lsces.co.uk wrote:

 With the arrival of a 'new' set of controls, and the discussion on
 front
 page, I feel that it IS necessary to open this discussion a little
 wider.
 Having been using the new interface on mobile devices I find it much
 less
 usable than the older set-up. But that is not to say that the old one
 was
 actually usable! There is a need for a different map interface that
 works
 better with mobile devices. Even the routing demos have mixed results
 on
 tablets and mobile phones. I've been working on my own 'front end'
 simply to
 provide one that I can tailor for the devices I am using. The old
 N900 used
 to work well, but the newer devices are difficult to use 'on the go'.
 As an
 example, the old TomTom sat nav was easy to use while driving, but the
 current replacements I've tried to use with the Galaxy4 can be
 dangerous at
 times as they wander off doing their own thing, and you have to stop
 to get
 back to a state where you can continue following the route.

 It's obvious that the new map interface is not designed for mobile
 devices,
 so where should we discuss that development and how it would fit in
 with an
 improved front end. It's not just a matter of directing to 'a map'
 but more
 important is directing to safe options for those of us who ARE using
 the
 tools every day. The current options are both difficult to find, and
 have
 clear information on how safe they are when using them live!
 Disclaimers of
 accepting no responsibility may cover any legal liability, but
 essentially
 say 'here is a tool - but you should never use it!'

 And discussion on a more open platform would also be appreciated
 rather than

Re: [OSM-talk] Upgraded map controls

On Jul 21, 2013, at 5:42 AM, Pieren wrote:

 On Sun, Jul 21, 2013 at 12:55 AM, Dave F. dave...@madasafish.com wrote:
 On 20/07/2013 12:57, Paul Norman wrote:
 
 Rails port pull requests?!?! wtf.
 :
 I really think some developers are living in their own world.
 
 lol. They do !
 If you missed the discussion because you don't watch the non-localized
 35 mailing lists, 5 irc channels, 13 forums, 8 foundation working
 groups reports, all pull requests discussions in github/osm and the
 videos of the last SOTM, it's really your fault :-)


Supporting official venues for orderly change is what the board should be 
doing, but is not. I would support the creation and use of a 
proposal/vote/implementation process for the community, even if the first 
proposal is just be it resolved that Mapbox accepts responsibility for the 
visual design of OSM.org.

The new icons and map controls are good and I'm getting accustomed to them, but 
the process by which they made it onto the site worries me. Mostly, it's 
because Saman opened his SotM-US talk with a blow it all up slide and 
finished with gamification that I'm uneasy with how we're treating the visual 
presentation of OSM.org. Gamification is a sad, sorry sideshow and we shouldn't 
do it; it only became a meme because Zynga made a zillion dollars and look how 
that turned out. Do we plan to follow through on gamifying the OSM UI as Saman 
suggested in his talk? I don't know, and I don't want to have to subscribe to 
Github pull requests to find out.

Let's not lose sight of the fact that OSM.org has mapped the world in a decade.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [OSM-talk] Upgraded map controls

Hey,

Let's also not lose the fact that this thread started with 'Should we
remove the +/- buttons' and has visited about 10 topics in 37 emails since
then. Maybe it's time to start fresh with a focused thread.

Tom


On Sun, Jul 21, 2013 at 2:18 PM, Michal Migurski m...@teczno.com wrote:

 On Jul 21, 2013, at 5:42 AM, Pieren wrote:

  On Sun, Jul 21, 2013 at 12:55 AM, Dave F. dave...@madasafish.com
 wrote:
  On 20/07/2013 12:57, Paul Norman wrote:
 
  Rails port pull requests?!?! wtf.
  :
  I really think some developers are living in their own world.
 
  lol. They do !
  If you missed the discussion because you don't watch the non-localized
  35 mailing lists, 5 irc channels, 13 forums, 8 foundation working
  groups reports, all pull requests discussions in github/osm and the
  videos of the last SOTM, it's really your fault :-)


 Supporting official venues for orderly change is what the board should be
 doing, but is not. I would support the creation and use of a
 proposal/vote/implementation process for the community, even if the first
 proposal is just be it resolved that Mapbox accepts responsibility for the
 visual design of OSM.org.

 The new icons and map controls are good and I'm getting accustomed to
 them, but the process by which they made it onto the site worries me.
 Mostly, it's because Saman opened his SotM-US talk with a blow it all up
 slide and finished with gamification that I'm uneasy with how we're
 treating the visual presentation of OSM.org. Gamification is a sad, sorry
 sideshow and we shouldn't do it; it only became a meme because Zynga made a
 zillion dollars and look how that turned out. Do we plan to follow through
 on gamifying the OSM UI as Saman suggested in his talk? I don't know, and I
 don't want to have to subscribe to Github pull requests to find out.

 Let's not lose sight of the fact that OSM.org has mapped the world in a
 decade.

 -mike.

 
 michal migurski- contact info and pgp key:
 sf/cahttp://mike.teczno.com/contact.html





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

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

Re: [OSM-talk] Upgraded map controls

2013-07-21 Thread Richard Fairhurst

Michal Migurski wrote:
 On Jul 21, 2013, at 5:42 AM, Pieren wrote:
  If you missed the discussion because you don't watch the 
  non-localized 35 mailing lists
  [...]
 I don't know, and I don't want to have to subscribe to Github 
 pull requests to find out.

You only have to follow one mailing list: rails-dev@. Just as if you're
interested in the development of JOSM you should follow josm-dev@, if you're
interested in the development of Potlatch you should follow potlatch-dev@,
if you're interested in the development of Merkaartor, OSRM, Nominatim, etc.
etc.

All site issues on github and site issues on trac are gatewayed to
rails-dev, so you won't miss anything.

(rails-dev is a daft, uninituitive name and really it should be called
site-dev, but history.)

Anticipating next message: Pieren will now complain that this public mailing
list is a secretive list as he traditionally does re: legal-talk@. :)

cheers
Richard





--
View this message in context: 
http://gis.19327.n5.nabble.com/Upgraded-map-controls-tp5770491p5770755.html
Sent from the General Discussion mailing list archive at Nabble.com.

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

Re: [OSM-talk] Upgraded map controls

On Jul 21, 2013, at 11:47 AM, Richard Fairhurst wrote:

 Michal Migurski wrote:
 On Jul 21, 2013, at 5:42 AM, Pieren wrote:
 If you missed the discussion because you don't watch the 
 non-localized 35 mailing lists
 [...]
 I don't know, and I don't want to have to subscribe to Github 
 pull requests to find out.
 
 You only have to follow one mailing list: rails-dev@. Just as if you're
 interested in the development of JOSM you should follow josm-dev@, if you're
 interested in the development of Potlatch you should follow potlatch-dev@,
 if you're interested in the development of Merkaartor, OSRM, Nominatim, etc.
 etc.
 
 All site issues on github and site issues on trac are gatewayed to
 rails-dev, so you won't miss anything.
 
 (rails-dev is a daft, uninituitive name and really it should be called
 site-dev, but history.)

Thank you Richard, I am subscribed. I had not realized that the scope of 
rails-dev was larger than the technical development and maintenance of the 
Rails port. For me, this explains past flame-outs of the design@ list.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [OSM-talk] New technology ...

2013-07-21 Thread lester

The problem is more fundamental than just bad routes, but I suspect Locus is 
part of the problem as all 4 routers have the same problem. Routing 
instructions through any junction with link_xxx gives a 'straight on' rather 
than advising to take the slip road. None of the posts to the relevant list 
have been answred!

While the generated instructions give better information, the lack of 'lane' 
information is the follow on that is also important. A standard for this 
interchange would also help ...

Sent from my android device.

-Original Message-
From: Tom MacWright t...@macwright.org
To: Lester Caine les...@lsces.co.uk
Cc: openstreetmap talk@openstreetmap.org
Sent: Sun, 21 Jul 2013 17:19
Subject: Re: [OSM-talk] New technology ...

Hi Lester,

The most productive way to lead to better routing on OSM is to find 'bad'
routes, generate permalinks on OSRM or your favorite tool, and post bug
reports, including what the desired route would be and what's incorrect
about the incorrect route. For OSRM in particular the bug tracker is here:
https://github.com/DennisOSRM/Project-OSRM/issues and you can click
'Generate Link' on the testing instance: http://map.project-osrm.org/ in
order to send a specific route around.

Tom


On Sun, Jul 21, 2013 at 12:02 PM, Lester Caine les...@lsces.co.uk wrote:

 Tom MacWright wrote:

 Hey Lester,

 I agree entirely - thus far we aren't focusing on the mobile version of
 the
 site. It's never been very polished, and recent changes aren't focused on
 improving it significantly.

 As far as why, it's pretty simple - changes to the site are extremely
 time-intensive because of its myriad uses and the necessity of having a
 community process. That is, we've needed to focus on specific parts of
 the site
 because, even if we agree that many things need to be done, we only have
 enough
 designers  developers to implement one or two things a month.

 And some of us are hampered by the choose of tools that was made
 previously!


  I think there are two solid ways forward here:

 First, which is admittedly less likely, is if anyone wants to adopt the
 task of
 maintaining, testing, and improving the mobile site, and pushing those
 changes
 through.

 There are a few options as a good starting point, but your 'third' point
 is probably accurate here.


  Second, which is more doable but more likely to get over-communicated, is
 for
 someone to write a simple page pointing to good mobile options. For
 instance,
 users of GPS units should easily find out about Garmin extracts,
 smartphone
 users should easily find editors that work on their phone or apps that use
 OpenStreetMap data.

 http://lsces.co.uk/wiki/**Mobile+Computinghttp://lsces.co.uk/wiki/Mobile+Computing:)
 But I'm getting bogged down by what does not work in each of the options
 and I don't have time to try the options that are missing. I need to switch
 from Locus to one of the other options just to establish where the
 identified safety issues actually arise from! If you can't trust a
 configuration then it's unusable, and that is part of the current problem.


  Independent OSM-based tools do a better job at the very specific use-cases
 people have on mobile - whereas the website focuses strongly on one use
 case,
 editing, and has no smartphone-compatible editors.

 Adding data via the tablet is easier than actually using it on the tablet
 ...


  (To tackle the inevitable points of argument that follow that: yes, there
 are
 things that do this, but we need to do better. No, there's no committee to
 decide and yes the best way to do it is to do it, even if it's very
 low-tech.)

 We need well documented user reports on the available tools rather than
 just 'choose the option that works for you' ... I have yet to find a
 routing package that gives SAFE directions on UK motorways! This was the
 whole reason for my closer investigation.

  Tom

 On Sun, Jul 21, 2013 at 11:26 AM, Lester Caine les...@lsces.co.uk
 mailto:les...@lsces.co.uk wrote:

 With the arrival of a 'new' set of controls, and the discussion on
 front
 page, I feel that it IS necessary to open this discussion a little
 wider.
 Having been using the new interface on mobile devices I find it much
 less
 usable than the older set-up. But that is not to say that the old one
 was
 actually usable! There is a need for a different map interface that
 works
 better with mobile devices. Even the routing demos have mixed results
 on
 tablets and mobile phones. I've been working on my own 'front end'
 simply to
 provide one that I can tailor for the devices I am using. The old
 N900 used
 to work well, but the newer devices are difficult to use 'on the go'.
 As an
 example, the old TomTom sat nav was easy to use while driving, but the
 current replacements I've tried to use with the Galaxy4 can be
 dangerous at
 times as they wander off doing their own thing, and you have to stop
 to get
 back to a state

Re: [OSM-talk] Upgraded map controls

It begs the question, if this high level design decisions shouldn't live on
the design@ list instead of rails-dev or in the git-hub bug tracker.

rails-dev can sometimes have a reasonably high volume and most of it is
boring technical detail, like e.g. if oauth needs relative or absolute URLs
to produce valid signatures. This is something most people don't (and
probably shouldn't) care about and won't read rails-dev. So putting high
level design discussions that does effect everyone who uses osm.org and
where because it is subjective, everyone can have a valid opinion on it, is
perhaps a bad idea. After all there is a specific list just for this kind of
purpose i.e. design@

Of cause fragmenting mailing-lists further and further is probably a bad
idea though as well.

Kai



Michal Migurski-2 wrote
 On Jul 21, 2013, at 11:47 AM, Richard Fairhurst wrote:
 
 Michal Migurski wrote:
 On Jul 21, 2013, at 5:42 AM, Pieren wrote:
 If you missed the discussion because you don't watch the 
 non-localized 35 mailing lists
 [...]
 I don't know, and I don't want to have to subscribe to Github 
 pull requests to find out.
 
 You only have to follow one mailing list: rails-dev@. Just as if you're
 interested in the development of JOSM you should follow josm-dev@, if
 you're
 interested in the development of Potlatch you should follow
 potlatch-dev@,
 if you're interested in the development of Merkaartor, OSRM, Nominatim,
 etc.
 etc.
 
 All site issues on github and site issues on trac are gatewayed to
 rails-dev, so you won't miss anything.
 
 (rails-dev is a daft, uninituitive name and really it should be called
 site-dev, but history.)
 
 Thank you Richard, I am subscribed. I had not realized that the scope of
 rails-dev was larger than the technical development and maintenance of the
 Rails port. For me, this explains past flame-outs of the design@ list.
 
 -mike.
 
 
 michal migurski- contact info and pgp key:
 sf/cahttp://mike.teczno.com/contact.html
 
 
 
 
 
 ___
 talk mailing list

 talk@

 http://lists.openstreetmap.org/listinfo/talk





--
View this message in context: 
http://gis.19327.n5.nabble.com/Upgraded-map-controls-tp5770491p5770758.html
Sent from the General Discussion mailing list archive at Nabble.com.

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

Re: [OSM-talk] Upgraded map controls

On Jul 21, 2013, at 12:28 PM, Kai Krueger wrote:

 It begs the question, if this high level design decisions shouldn't live on
 the design@ list instead of rails-dev or in the git-hub bug tracker.
 
 rails-dev can sometimes have a reasonably high volume and most of it is
 boring technical detail, like e.g. if oauth needs relative or absolute URLs
 to produce valid signatures. This is something most people don't (and
 probably shouldn't) care about and won't read rails-dev. So putting high
 level design discussions that does effect everyone who uses osm.org and
 where because it is subjective, everyone can have a valid opinion on it, is
 perhaps a bad idea. After all there is a specific list just for this kind of
 purpose i.e. design@
 
 Of cause fragmenting mailing-lists further and further is probably a bad
 idea though as well.

I do like Richard's thought that rails-dev should be site-dev, if a 
renaming was accompanied with the merging of the design@ list. We'd come out 
with a less-fragmented and clearer selection of mailing lists!

It makes sense to me that the people making design suggestions and those who 
implement them participate in the same conversation space, even if the 
designers need to occasionally skip an OAuth thread or the developers get bored 
of hearing about hex colors and corner radii.

The key though is delegation and recordkeeping. If we should decide that Saman 
+ Mapbox own the visual design of the site for a period of time, we need to be 
clear that that includes credit, accountability, and a paper trail of 
deliberations that we can point to when someone asks if we really need plus and 
minus buttons on the map.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





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

Re: [OSM-talk] Upgraded map controls

2013-07-21 Thread Maarten Deen


On 2013-07-21 20:18, Michal Migurski wrote:


The new icons and map controls are good and I'm getting accustomed to
them, but the process by which they made it onto the site worries me.


IMHO at the moment they have become superfluous. There is no way anymore 
to zoom in or out more than one step at a time by using on-map controls 
as there was with the old slider. So I'm using the mouse now to zoom in 
or out. It's much faster than the +/- buttons.

As far as I'm concerned they can be removed.

Maarten

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

Re: [OSM-talk] New technology ...

lsces wrote
 With the arrival of a 'new' set of controls, and the discussion on front
 page, I 
 feel that it IS necessary to open this discussion a little wider. Having
 been 
 using the new interface on mobile devices I find it much less usable than
 the 
 older set-up. But that is not to say that the old one was actually usable!

As always this is somewhat subjective. Whereas on the desktop, I don't yet
see much of an advantage* other than that it is prettier, I think it has
somewhat improved the usage on a mobile phone. The larger + - buttons make
them more touch friendly (pinch to zoom is very erratic and often doesn't
work at all for me) and the new geolocation functionality is a pretty neat
feature particularly for mobile use! The notes functionality, which can be
useful on a mobile, could probably do with some improvements (the bubbles
are to big to fit on a 5 screen properly), but overall are usable.  iD
pretty much doesn't work at all on a phone, but then editing on a 4 touch
screen or on a 24 monitor with mouse and keyboard really are two very
different beasts and can't really be used in the same design. There you
simply want separate special purpose apps like Vespucci. 

One question would therefore be, what functionality of osm.org would you
hope to actually be able to use on a mobile phone? 

Browsing the map and adding / checking bugs seem like the most likely
candidates. Imho, those work reasonably well with the new design and can
probably be fixed up with some specific minor tweaks.

For sat-navs and more sophisticated map applications there are a bunch of
special purpose apps, some of which work quite well already.

Kai

* Once the improvements of the share menu go in, that should change and
actually add real functionality to the map, which I am looking forward to.



--
View this message in context: 
http://gis.19327.n5.nabble.com/New-technology-tp5770731p5770762.html
Sent from the General Discussion mailing list archive at Nabble.com.

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

Re: [OSM-talk] New technology ...

For what it's worth, for those who want to use the Notes facility of OSM
remotely, I've worked on a predictably open source
https://github.com/osmlab/osm-note boringly named project called OSM Note,
that you can open on your phone like so
http://osmlab.github.io/osm-note/and place notes, log in, and so on.


On Sun, Jul 21, 2013 at 3:55 PM, Kai Krueger kakrue...@gmail.com wrote:

 lsces wrote
  With the arrival of a 'new' set of controls, and the discussion on front
  page, I
  feel that it IS necessary to open this discussion a little wider. Having
  been
  using the new interface on mobile devices I find it much less usable than
  the
  older set-up. But that is not to say that the old one was actually
 usable!

 As always this is somewhat subjective. Whereas on the desktop, I don't yet
 see much of an advantage* other than that it is prettier, I think it has
 somewhat improved the usage on a mobile phone. The larger + - buttons make
 them more touch friendly (pinch to zoom is very erratic and often doesn't
 work at all for me) and the new geolocation functionality is a pretty neat
 feature particularly for mobile use! The notes functionality, which can be
 useful on a mobile, could probably do with some improvements (the bubbles
 are to big to fit on a 5 screen properly), but overall are usable.  iD
 pretty much doesn't work at all on a phone, but then editing on a 4 touch
 screen or on a 24 monitor with mouse and keyboard really are two very
 different beasts and can't really be used in the same design. There you
 simply want separate special purpose apps like Vespucci.

 One question would therefore be, what functionality of osm.org would you
 hope to actually be able to use on a mobile phone?

 Browsing the map and adding / checking bugs seem like the most likely
 candidates. Imho, those work reasonably well with the new design and can
 probably be fixed up with some specific minor tweaks.

 For sat-navs and more sophisticated map applications there are a bunch of
 special purpose apps, some of which work quite well already.

 Kai

 * Once the improvements of the share menu go in, that should change and
 actually add real functionality to the map, which I am looking forward to.



 --
 View this message in context:
 http://gis.19327.n5.nabble.com/New-technology-tp5770731p5770762.html
 Sent from the General Discussion mailing list archive at Nabble.com.

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

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

Re: [OSM-talk] Upgraded map controls

2013-07-21 Thread Frederik Ramm


Hi,

On 21.07.2013 21:28, Kai Krueger wrote:

It begs the question, if this high level design decisions shouldn't live on
the design@ list instead of rails-dev or in the git-hub bug tracker.


Yes, I can imagine that to some a you only have to follow rails-dev is 
a very hitchhikers-guidesque response.


My impression is this:

1. Lots of people re-iterate the mantra that mailing lists (and talk 
in particular) are places where you'll only get flak for all your good 
ideas, and endless bikeshedding, and whatnot. I think that this is not 
supported by facts.


2. Therefore if you do something you're tempted to ignore the mailing 
lists, as everyone tells you they're the pits of hell.


3. Therefore, people on the mailing lists - even the majority that is 
not troublemakers - feel sidelined, and complain.


Often even *informing* people in advance could help a lot.

I think that the situation would already be much improved if, when 
something of greater importance pops up on rails-dev or elsewhere, 
someone informs the talk list about that. For example, in the specific 
case, once TomH had set up the working branch with the new UI, a quick 
note should have gone up on talk: look here this new design, being 
discussed here in case you want to say something. A couple of people 
might want to say something but the majority will just be pleased to 
have been told about it.


Anyone can do this cross-pollination of the talk list, and maybe we 
should make it a habit.


I'll start with:

Hi everyone, there's an idea to provide a new welcome/landing page 
used to send new users to, or maybe those who come to OSM via one of the 
sites using OSM maps. It can be viewed here


http://welcome.apis.dev.openstreetmap.org/welcome

and the discussion is here

https://github.com/openstreetmap/openstreetmap-website/pull/338

Bye
Frederik

PS: If I reply to a message on rails-dev, will it land in the proper 
github ticket discussion? I tried it once a while ago and found that my 
comments were not there, and it seemed that some people were reading via 
rails-dev and got my message while others were reading via github and 
didn't. Has someone successfully used the write portion of the gateway?


--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

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

Re: [OSM-talk] Upgraded map controls

2013-07-21 Thread Yohan Boniface


On 07/21/2013 09:49 PM, Maarten Deen wrote:

IMHO at the moment they have become superfluous. There is no way anymore
to zoom in or out more than one step at a time by using on-map controls
as there was with the old slider. So I'm using the mouse now to zoom in
or out.


Maybe not everybody knows this: in Leaflet maps, if you press Shift 
while clicking on +/- buttons, you zoom/unzoom with a factor 3. And so 
(as we are using Leaflet) it is the case on osm.org.


Yohan

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

Re: [OSM-talk] New technology ...

lsces wrote
The problem is more fundamental than just bad routes, but I suspect Locus
is part of the problem as all 4 routers have the same problem. Routing
instructions through any junction with link_xxx gives a 'straight on'
rather than advising to take the slip road. None of the posts to the
relevant list have been answred!

OK, this goes so much beyond the change of a few controls on the website, or
any website UI design. It really should be an entirely different topic, as
this has nothing to do with usability, but goes at the hart of the core
data-model and its applicability to turn-by-turn navigation.

lsces wrote
While the generated instructions give better information, the lack of
'lane' information is the follow on that is also important. A standard for
this interchange would also help ...

There are proposals for lane tagging lanes
http://wiki.openstreetmap.org/wiki/Lane; and
http://wiki.openstreetmap.org/wiki/Key:turn;. There are even mobile apps
that already use this information where available to provide lane assist.
MapFactor Free being one of them
(http://forum.mapfactor.com/discussion/435/how-to-make-turn-lanes-in-osm-appear-in-mapfactor-free/p1
), I think OSMAnd also supports this. The problem is that there are so far
only few roads mapped with this information

But as with any tagging schema, it is really up to the mappers and data
users to come up with good proposals that work for both and standardize
them.

I am hoping that eventually routing will become part of the main site, to
help guide and improve the whole routing situation and incentivize mappers
to really map the necessary information in a way that is processable by a
routing engine.

Kai

--
View this message in context:
http://gis.19327.n5.nabble.com/New-technology-tp5770731p5770766.html
Sent from the General Discussion mailing list archive at Nabble.com.

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

Re: [OSM-talk] Upgraded map controls

2013-07-21 Thread Maarten Deen


On 2013-07-21 22:06, Yohan Boniface wrote:

On 07/21/2013 09:49 PM, Maarten Deen wrote:
IMHO at the moment they have become superfluous. There is no way 
anymore

to zoom in or out more than one step at a time by using on-map controls
as there was with the old slider. So I'm using the mouse now to zoom in
or out.

Maybe not everybody knows this: in Leaflet maps, if you press Shift
while clicking on +/- buttons, you zoom/unzoom with a factor 3. And so
(as we are using Leaflet) it is the case on osm.org.


So it's what Frederik says, but it goes further. Not only does noone get 
informed, when there are changes noone (except the developers and maybe 
the happy few that get told) know how to use the new interface.


That's the second thing I had to find out by first complaining that it 
doesn't work.
And that's not a good thing. I find it out here. How does someone who 
only uses the map find out?


Maarten


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

Re: [OSM-talk] Upgraded map controls

2013-07-21 Thread Yohan Boniface


Humm...
Just to be clear: I'm not involved in anyway in osm.org redesign.
I've given this tip because it seems to me that the topic was about 
keeping or not the +/- buttons, and imho it's a useful tip for people 
who, like me, doesn't use a mouse.


Yohan

On 07/21/2013 10:47 PM, Maarten Deen wrote:

On 2013-07-21 22:06, Yohan Boniface wrote:

On 07/21/2013 09:49 PM, Maarten Deen wrote:
IMHO at the moment they have become superfluous. There is no way anymore
to zoom in or out more than one step at a time by using on-map controls
as there was with the old slider. So I'm using the mouse now to zoom in
or out.

Maybe not everybody knows this: in Leaflet maps, if you press Shift
while clicking on +/- buttons, you zoom/unzoom with a factor 3. And so
(as we are using Leaflet) it is the case on osm.org.


So it's what Frederik says, but it goes further. Not only does noone get
informed, when there are changes noone (except the developers and maybe
the happy few that get told) know how to use the new interface.

That's the second thing I had to find out by first complaining that it
doesn't work.
And that's not a good thing. I find it out here. How does someone who
only uses the map find out?

Maarten


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



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

Re: [OSM-talk] New technology ... Routing instructions

Kai Krueger wrote:

lsces wrote

The problem is more fundamental than just bad routes, but I suspect Locus
is part of the problem as all 4 routers have the same problem. Routing
instructions through any junction with link_xxx gives a 'straight on'
rather than advising to take the slip road. None of the posts to the
relevant list have been answred!

It is a new topic?
That's why I started a new thread ... but this is a slight sideline off the
usability problem of the map itself on mobile devices, so changed the subject.
It is all bundled with mobile use of the map data though.

lsces wrote

While the generated instructions give better information, the lack of
'lane' information is the follow on that is also important. A standard for
this interchange would also help ...

I was rush this on the move ...
The interchange *I* was talking about was the level above, and related to how a
routing engine presents the list of directions that go with a track. The slip
road for a roundabout gets described several ways between the different engines,
and none is ideal for generating the correct basic move instructions. THEN you
add improved instructions by including the appropriate lane and other road
layout details? Currently I'm getting 'straight on' for the slip road when at
the very least it should be 'take the slip road'? If I'm not careful I've passed
the slip road before I get the 'take the first exit' !

But as with any tagging schema, it is really up to the mappers and data
users to come up with good proposals that work for both and standardize
them.

I have come to the conclusion that while it would perhaps be nice to have a
routing engine accessible from the map, there is even more reason to have a
number of routers each with their own optimised way of working. Once one gets to
routing, one size will never fit all, and may well be very much location driven.
The four routing engines I'm currently comparing all give different advantages
and disadvantages ... as well as quite regularly different routes for the same
journey. Which is why I'm looking into running my own engine which I can tailor
to my preferred 'short cuts' ...

--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] New technology ...


Kai Krueger wrote:

One question would therefore be, what functionality of osm.org would you
hope to actually be able to use on a mobile phone?


Browsing the map to see if an alternate route might be better. Not knowing where 
one is scale wise, the old scale bar provides an easy and quick to read and one 
can judge if you need to zoom out a lot or a little. But basic functions for 
using the map need to be simple.


Currently I'm only seeing the top 4 new right hand buttons, and I can't read the 
scale at all which is why I've reverted to my own viewer, but the main thing 
here is that you CAN'T use multiple fingers while driving! So the viewing 
arrangement I'm looking at - from a SAFETY point of view - is one that can be 
controlled just by prodding with one finger. Eliminating anything 'fancy' since 
it is just not practical to use? Even the tomtom's latest 'upgrades' lost the 
plot and made using the unit a problem and I know I was not the only one to roll 
back to the 'safe' version!


Trying to press a shift or control key is also not practical ... Locus has a 
number of actions that make use impractical once moving.


Note that I'm not saying that the main map should change - this is mobile 
technology use, but personally I WOULD like to have the option to select the old 
style layout. It's not fundamental to how the map works - it's only a style 
sheet, and we could have several - including mobile centric ones? What rattles 
my cage is when someone else changes things that I'm naturally used to when 
there is no need to FORCE me to change - just put an option to select in!


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] New technology ...

lsces wrote
 Kai Krueger wrote:
 One question would therefore be, what functionality of osm.org would you
 hope to actually be able to use on a mobile phone?
 
 Browsing the map to see if an alternate route might be better. Not knowing
 where 
 one is scale wise, the old scale bar provides an easy and quick to read
 and one 
 can judge if you need to zoom out a lot or a little. But basic functions
 for 
 using the map need to be simple.

On Firefox for android, Android stock browser and Chrome for Android I see
the scale bar clearly at the bottom that tells me much better what the scale
is than the zoom scale bar. Opera for Android partially obscures the scale
bar with the lower menu. If you don't see the scale bar on your phone, then
that probably is a bug somewhere and should be fixed.


lsces wrote
 Currently I'm only seeing the top 4 new right hand buttons, and I can't
 read the 
 scale at all which is why I've reverted to my own viewer, but the main
 thing 
 here is that you CAN'T use multiple fingers while driving! So the viewing 
 arrangement I'm looking at - from a SAFETY point of view - is one that can
 be 
 controlled just by prodding with one finger.

Osm.org is not designed to be used while driving and you really shouldn't be
using it while driving, as you quite rightfully state it is not safe to use.
The cartography of the OSM.org tiles are also not in anyway appropriate for
reading the map while driving. I mean you wouldn't stick a paper map on your
windscreen either and try and use it to navigate as a driver?

If you are trying to use it for driving (as a driver), use one of the
sat-nav apps like OsmAnd, Mapfactor Free, NavMII free, Skobbler, or the
various other options that exist for android and other mobile platforms. If
those apps give you wrong directions and you need to find your own
alternative route, then you will have to pull to the side and stop while
re-orienting, or give the phone to a passenger that has hands free and can
direct you.

This is not (and will never be) the job of osm.org and so it imho isn't a
valid use case to optimize the UI of osm.org for. It is probably not even
legal to operate your phone this way while driving. 


lsces wrote
 Note that I'm not saying that the main map should change - this is mobile 
 technology use, but personally I WOULD like to have the option to select
 the old 
 style layout. It's not fundamental to how the map works - it's only a
 style 
 sheet, and we could have several - including mobile centric ones?

It is quite a lot of work to keep multiple options working, tested and in
sync. As there is a shortage of developers for the main website already
anyway and one needs to prioritize what can be achieved, this seems rather
low on the priority list. Perhaps in the future someone will submit a patch
to implement something like Wikipedia's user styles which might solve some
of your issues. 

Well, actually, there are already different styles as part of the CSS for
mobile and printers to optimize for different viewing patterns.

I am not a fan of just changing things to make them prettier without
adding functionality, or even less of the website hasn't changed in X
years, we need to change things to make it modern either, but having
multiple versions beyond what we already have is just likely not really
feasible at the moment. There are imho more important things to fix or
optimize.


Kai



--
View this message in context: 
http://gis.19327.n5.nabble.com/New-technology-tp5770731p5770783.html
Sent from the General Discussion mailing list archive at Nabble.com.

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

[OSM-talk] Double-clicking on OSM map does not centre the map

2013-07-21 Thread Andrew Errington

It used to be that if you double-clicked on the map it would re-centre
on the clicked point and zoom in by one level.  Now it doesn't.  It
zooms in, but doesn't re-centre the map.  When did this behaviour
change?  Is it desirable?

I don't like it because now I can't centre the map (by
double-clicking) and make a markerlink (by editing the permalink
lat/lon to mlat/mlon).

Best wishes,

Andrew

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

Re: [OSM-talk] Double-clicking on OSM map does not centre the map

2013-07-21 Thread Clay Smalley

I've noticed the same issue. I liked having an easy way to center the map.
Is anyone averse to having this changed back?
On Jul 21, 2013 8:02 PM, Andrew Errington erringt...@gmail.com wrote:

 It used to be that if you double-clicked on the map it would re-centre
 on the clicked point and zoom in by one level.  Now it doesn't.  It
 zooms in, but doesn't re-centre the map.  When did this behaviour
 change?  Is it desirable?

 I don't like it because now I can't centre the map (by
 double-clicking) and make a markerlink (by editing the permalink
 lat/lon to mlat/mlon).

 Best wishes,

 Andrew

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

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

Re: [OSM-talk] Double-clicking on OSM map does not centre the map

The relevant change in Leaflet:
https://github.com/Leaflet/Leaflet/pull/1582?source=cc - the new behavior
matches all other map sites and frameworks I can think of, with the
exception of Bing. You can replicate the old behavior by clicking the map
and dragging it to change the center.

There's no easy way to 'get the old behavior back' without doing a core
patch to Leaflet, and given that this is the expected behavior with a clear
'other way to do it', I personally don't think it's a high priority to
change.


On Sun, Jul 21, 2013 at 11:26 PM, Clay Smalley claysmal...@gmail.comwrote:

 I've noticed the same issue. I liked having an easy way to center the map.
 Is anyone averse to having this changed back?
  On Jul 21, 2013 8:02 PM, Andrew Errington erringt...@gmail.com wrote:

 It used to be that if you double-clicked on the map it would re-centre
 on the clicked point and zoom in by one level.  Now it doesn't.  It
 zooms in, but doesn't re-centre the map.  When did this behaviour
 change?  Is it desirable?

 I don't like it because now I can't centre the map (by
 double-clicking) and make a markerlink (by editing the permalink
 lat/lon to mlat/mlon).

 Best wishes,

 Andrew

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


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


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

Re: [OSM-talk] Double-clicking on OSM map does not centre the map

2013-07-21 Thread John Firebaugh

The rationale for making the change in Leaflet is to make it so that you
can zoom in several levels on a given point without needing to reposition
your cursor at each zoom level. For that reason, I prefer the new behavior.

Included in the next set of changes to the map UI is the ability to add a
marker to the permalink. It will be positionable via dragging. No URL
editing required:

http://mapui.apis.dev.openstreetmap.org/


On Sun, Jul 21, 2013 at 9:00 PM, Tom MacWright t...@macwright.org wrote:

 The relevant change in Leaflet:
 https://github.com/Leaflet/Leaflet/pull/1582?source=cc - the new behavior
 matches all other map sites and frameworks I can think of, with the
 exception of Bing. You can replicate the old behavior by clicking the map
 and dragging it to change the center.

 There's no easy way to 'get the old behavior back' without doing a core
 patch to Leaflet, and given that this is the expected behavior with a clear
 'other way to do it', I personally don't think it's a high priority to
 change.


 On Sun, Jul 21, 2013 at 11:26 PM, Clay Smalley claysmal...@gmail.comwrote:

 I've noticed the same issue. I liked having an easy way to center the
 map. Is anyone averse to having this changed back?
  On Jul 21, 2013 8:02 PM, Andrew Errington erringt...@gmail.com
 wrote:

 It used to be that if you double-clicked on the map it would re-centre
 on the clicked point and zoom in by one level.  Now it doesn't.  It
 zooms in, but doesn't re-centre the map.  When did this behaviour
 change?  Is it desirable?

 I don't like it because now I can't centre the map (by
 double-clicking) and make a markerlink (by editing the permalink
 lat/lon to mlat/mlon).

 Best wishes,

 Andrew

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


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



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


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

Re: [OSM-talk] Double-clicking on OSM map does not centre the map

2013-07-21 Thread Clay Smalley

That's totally understandable. Though to do that, I usually scroll. I'm
accustomed to behavior where I scroll if I want to zoom without centering,
and double click if I want to zoom and center.

Though I'm sure there are issues like touch screen interfaces where using a
scroll wheel isn't an option. I totally support the change, and I'm sure
I'll get used to it soon enough.
On Jul 21, 2013 9:36 PM, John Firebaugh john.fireba...@gmail.com wrote:

 The rationale for making the change in Leaflet is to make it so that you
 can zoom in several levels on a given point without needing to reposition
 your cursor at each zoom level. For that reason, I prefer the new behavior.

 Included in the next set of changes to the map UI is the ability to add a
 marker to the permalink. It will be positionable via dragging. No URL
 editing required:

 http://mapui.apis.dev.openstreetmap.org/


 On Sun, Jul 21, 2013 at 9:00 PM, Tom MacWright t...@macwright.org wrote:

 The relevant change in Leaflet:
 https://github.com/Leaflet/Leaflet/pull/1582?source=cc - the new
 behavior matches all other map sites and frameworks I can think of, with
 the exception of Bing. You can replicate the old behavior by clicking the
 map and dragging it to change the center.

 There's no easy way to 'get the old behavior back' without doing a core
 patch to Leaflet, and given that this is the expected behavior with a clear
 'other way to do it', I personally don't think it's a high priority to
 change.


 On Sun, Jul 21, 2013 at 11:26 PM, Clay Smalley claysmal...@gmail.comwrote:

 I've noticed the same issue. I liked having an easy way to center the
 map. Is anyone averse to having this changed back?
  On Jul 21, 2013 8:02 PM, Andrew Errington erringt...@gmail.com
 wrote:

 It used to be that if you double-clicked on the map it would re-centre
 on the clicked point and zoom in by one level.  Now it doesn't.  It
 zooms in, but doesn't re-centre the map.  When did this behaviour
 change?  Is it desirable?

 I don't like it because now I can't centre the map (by
 double-clicking) and make a markerlink (by editing the permalink
 lat/lon to mlat/mlon).

 Best wishes,

 Andrew

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


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



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



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


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

Re: [OSM-talk] Double-clicking on OSM map does not centre the map

2013-07-21 Thread Maarten Deen


On 2013-07-22 06:33, John Firebaugh wrote:

The rationale for making the change in Leaflet is to make it so that
you can zoom in several levels on a given point without needing to
reposition your cursor at each zoom level. For that reason, I prefer
the new behavior.


Zooming in by using the scroll-wheel did the same in the old framework. 
Basically the new framework removes functionality. I don't think that's 
a good idea.


I hadn't noticed this yet, but IMHO it's a bad thing. There are 
occasions when I am looking for a particular point to be the map center. 
Dragging the map to the center is no solution because my sight is not 
absolute and I do not know what the center of my browserscreen is.



Included in the next set of changes to the map UI is the ability to
add a marker to the permalink. It will be positionable via dragging.
No URL editing required:

http://mapui.apis.dev.openstreetmap.org/ [3]


It is nice to give a link to the development map (at least I assume it 
is), but how do you set that marker?


Regards,
Maarten

On Sun, Jul 21, 2013 at 9:00 PM, Tom MacWright t...@macwright.org 
wrote:


The relevant change in 
Leaflet: https://github.com/Leaflet/Leaflet/pull/1582?source=cc [1] - 
the new behavior matches all other map sites and frameworks I can think 
of, with the exception of Bing. You can replicate the old behavior by 
clicking the map and dragging it to change the center.


There's no easy way to 'get the old behavior back' without doing a core 
patch to Leaflet, and given that this is the expected behavior with a 
clear 'other way to do it', I personally don't think it's a high 
priority to change.


On Sun, Jul 21, 2013 at 11:26 PM, Clay Smalley claysmal...@gmail.com 
wrote:


I've noticed the same issue. I liked having an easy way to center the 
map. Is anyone averse to having this changed back?


On Jul 21, 2013 8:02 PM, Andrew Errington erringt...@gmail.com 
wrote:

It used to be that if you double-clicked on the map it would re-centre
on the clicked point and zoom in by one level.  Now it doesn't.  It
zooms in, but doesn't re-centre the map.  When did this behaviour
change?  Is it desirable?

I don't like it because now I can't centre the map (by
double-clicking) and make a markerlink (by editing the permalink
lat/lon to mlat/mlon).

Best wishes,

Andrew

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk [2]

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk [2]

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk [2]



Links:
--
[1] https://github.com/Leaflet/Leaflet/pull/1582?source=cc
[2] http://lists.openstreetmap.org/listinfo/talk
[3] http://mapui.apis.dev.openstreetmap.org/

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


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

[talk-au] mkgmap and matching mapnik styles and typ files

2013-07-21 Thread Brett Russell

Hi 

Thanks greatly to a fellow forum member I am making progress with mkgmap 
running on Windows 7.  But I have struck a problem.  mapnik uses an array of 
icons such as my favourite been the alpine_hut one.  To get this to work you 
need to feed the outcome of a style sheet into a type file to produce an img 
file else you are limited to the standard Garmin ones.  This means that the 
style file and typ file need to match else you get weird icons cropping up 
through the mismatch.  Now it is easy enough to get hold of the mapnik typ file 
but the matching style sheet has proven elusive, remarkably so given the normal 
ease of finding things on OSM.  

Now before someone yet again refers me to that dreaded  openmtb site I am 
looking to create Garmin maps that are optimised for Australian conditions not 
some European idea of mapping.  Goodness knows we know how little they 
understand our 4Wd issues and even less on our bushwalking ones!  By Australian 
conditions I mean ones that have zoom levels that hold huts, tracks and 
mountain in at 12km level.  Sure in Europe such zoom level detail would result 
in so much screen clutter as to be useless but we are living in a vast country. 
 I have by playing with the default style and using the mapnik style sheet to 
generate a better working map by altering the resolution levels.   

The results are getting there but rather than hand match the default mkgmap 
style to the mapnik style sheet that I have I am hoping that the matching style 
sheet exists and more importantly available rather than some covert 
commercialization attempt.  If it is commercial property then fine, I will 
develop my own style and typ sheets, just will take a longer time than starting 
with a combination that will produce mapnik styles that we are familiar with in 
our editing.

Also I have been looking at the mkgmap process and realizing that you can 
render a lot of things better.  A good example is the much debated 4wd issue.  
Lets say we use default tags such as surface=unpaved and if you like 
4wd_only=yes to keep in good with the European mappers but then use a new tag 
unpaved= 2wd-car, 2wd-high_clearance, 4wd-light, 4wd-heavy just as an example.  
Then with the conditional command in the mkgmap style generate a hex code that 
is matched to a line type in the typ file.  Now the Norwegians are doing 
something similar with hiking trails.  If I am correct in my understanding of 
the mkgmap style and typ relationship the above should work.  It means that the 
standard maps will work as normal but specialised 4WD ones can exist.  It is 
similar to rivers.  For most people river, stream and intermittent=yes/no are 
fine.  But for a kayaker a water grade of 1 to 6 is used.  Most people would 
not want the river appearing in multiple colours for each grade but for a 
kayaker such information is important.  

As more and more people are realising there is no one map style to suit all 
purposes so let the Europeans be guardians of the generic styles but allow 
various interest groups to add sub types.  Trouble is the OSM_inspector will 
flag such subtypes as invalid but that is only a matter of what is allowed or 
not.  Heck, Polatch 2 ignored natural=peak while Polatch 1 supported this tag.

Anyway, first a reference to a match mapnik style and typ combinations would be 
great.  And secondly a discussion on using an unpaved=?,?,? type approach.  I 
will need to do some testing to see if my ideas will work as if they do not 
then it is just wishful thinking on my part.  I am will be picking on Urks Road 
as that starts 2wd_car, then 2wd high clearance, onto 4wd-light and finally 
needing a serious 4wd.  I prefer descriptive labels as grade 1 to 10 will need 
to be explained.  Sure, it is subjective but so is any grading system as even 
debates rage within government road managers on type A, B, and C roads.  

Cheers Brett
  ___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-br] Encontro de mapeadores em BH

2013-07-21 Thread Blademir Andrade de Lima

Se eu pudesse eu iria, sou do sul de minas, mas estou sem recursos.
Blademir Andrade de Lima

Abraço

Date: Sat, 20 Jul 2013 15:02:58 -0300
From: vitor.d...@gmail.com
To: talk-br@openstreetmap.org
Subject: Re: [Talk-br] Encontro de mapeadores em BH

Pessoal,
A nova sugestão de data é 23 de agosto. Tá legal pra todo mundo?
Abraços!
Vítor Rodrigo Dias

Revisor de textos
Tradutor port/ing/port e port/esp/port
Telefone: (31) 9895-3975 - TIM

Em 16 de julho de 2013 22:44, Vítor Rodrigo Dias vitor.d...@gmail.com 
escreveu:

Samuel,
A gente pode ver sim, quem sabe também numa sexta. Mais alguém se habilita?
Vítor Rodrigo Dias
Revisor de textos

Tradutor port/ing/port e port/esp/port
Telefone: (31) 9895-3975 - TIM

Em 16 de julho de 2013 17:06, Samuel Vale srcv...@minaslivre.org escreveu:

Em Ter, 2013-07-16 às 14:24 -0300, Vítor Rodrigo Dias escreveu:

 Pessoal,

 O usuário nesol vai estar em Belo Horizonte em breve e sugeriu um

 encontro de mapeadores OSM. A data sugerida é 13 de agosto.

 Alguém mais aqui de BH topa esse encontro?

Opa, eu topo! Não há possibilidade de transferir para um sábado?

Até,

--

Samuel Vale srcv...@minaslivre.org

___

Talk-br mailing list

Talk-br@openstreetmap.org

http://lists.openstreetmap.org/listinfo/talk-br

___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br 
  ___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Maneira fácil de selecionar polígonos fácil.

2013-07-21 Thread Erick de Oliveira Leal

Olá pessoal, existe alguma maneira de selecionar todos polígonos que estão
no JOSM?
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Maneira fácil de selecionar polígonos fácil.

2013-07-21 Thread Fernando Trebien

Bem, há 2 tipos de polígonos no OSM: polígonos simples (objetos way
com a propriedade closed) e multipolígonos.

Para selecionar o primeiro tipo, basta dar um Ctrl+F (pra abrir a
janela de busca) e procurar por closed (sem as aspas).

Para o segundo, é interessante saber como funciona a função de busca
do JOSM. Você sempre busca por uma expressão. Um exemplo: se você
buscar por highway=primary, vai selecionar todos os objetos com essa
tag (inclusive nodos e relações, se elas a tiverem, mesmo que seja um
erro). Você pode buscar por dois critérios simultâneos. No exemplo
anterior, se você só quiser as vias primárias e não os nós e relações
incorretos, pode buscar por type:way highway=primary. O espaço em
branco significa a operação de e lógico: A B equivale a A e B
verdadeiros. Para um ou, você escreve A OR B. Se você quiser vias
primárias ou secundárias, a busca fica type:way highway=primary OR
highway=secondary. Você pode procurar por expressões negativas também
colocando um - na frente daquilo que você não quer selecionado. Por
exemplo, se quiser todas as vias que não são primárias, a expressão
fica type:way -highway=primary (inclui vias sem a tag highway).

As expressões nem sempre são tão convenientes e fáceis de escrever,
então você pode mudar o modo de busca de replace selection (padrão)
para add to selection, remove from selection e find in
selection. São equivalentes a expressões com ou, não e e,
respectivamente. Por exemplo, você pode buscar primeiro por type:way
no modo replace selection e depois buscar por type=primary no modo
remove from selection pra obter exatamente o mesmo resultado que no
exemplo anterior.

Se você também precisar das relações que são polígonos, você pode
pesquisar por objetos do tipo relation que têm a tag
type=multipolygon. Você escreve isso assim: type:relation
type=multipolygon. type:relation seleciona todos os objetos do tipo
relation, se você quisesse nodos seria type:node, e type=multipolygon
filtra desses objetos os que têm a tag type=multipolygon. Como há um
espaço em branco entre os dois, só vem no resultado aquilo que
satisfizer ambas as condições. Mas você pode fazer da maneira em dois
passos que eu disse antes.

Há outros tipos de relações que também funcionam como polígonos, por
exemplo, type:relation type=boundary e type:relation type=site.
Daí você tem que fazer uma busca para cada caso.

Às vezes ajuda copiar tudo (Ctrl+A) para uma outra camada e ir
trabalhando nela por eliminação. Você pode selecionar todas a relações
que não são nem multipolygon nem boundary com type:relation
-type=multipolygon -type=boundary (ou com duas buscas usando o modo
remove from selection). Daí pra saber os tipos que sobraram basta
olhar quais relações foram selecionadas na janela Selection à direita
(se não estiver aparecendo, vai em Window  Selection).

Recomendo essa leitura também:
http://wiki.openstreetmap.org/wiki/JOSM/Search_function

2013/7/21 Erick de Oliveira Leal erickdeoliveiral...@gmail.com:
 Olá pessoal, existe alguma maneira de selecionar todos polígonos que estão
 no JOSM?

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-br




-- 
Fernando Trebien
+55 (51) 9962-5409

The speed of computer chips doubles every 18 months. (Moore's law)
The speed of software halves every 18 months. (Gates' law)

___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

[Talk-de] Accounts zusammenlegen

2013-07-21 Thread Benjamin John

Hallo zusammen,
aus mir nicht mehr nachvollziehbaren Gründen habe ich zwei OSM-Accounts.
Da ich aber nur mit einem arbeite, liegt der andere brach, ist also eine
sogenannte Karteileiche (was ist eigentlich eine Kartei :-) )
Nun würde ich gern die beiden Accounts zusammenlegen zu einem einzigen,
da ich mit dem jetzt nicht mehr benutztem am Anfang doch einiges erfasst
habe. (Wäre halt gut für die Statistik :-) )

Kann mir jemand sagen, ob das überhaupt geht, und wenn ja wie? Oder wen
ich diesbezüglich fragen kann?

Sonnigen Sonntag wünscht
Benjamin


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Sinn und Unsinn von Fehlermeldungen (auf osm.org)

2013-07-21 Thread Dirk Sohler

Tirkon schrieb:
 Daraus ergibt sich, dass diese Fehlermeldungen auf den Meldeseiten
 verschimmeln, egal ob gefixt oder nicht.

Es fehlt schlicht die Integration in den Workflow. So lange
Fehlermeldungen irgendwas optionales sind, das man nur sieht, wenn man
bewusst draufklickt, wird sich das auch nicht ändern.

Fehlermeldungen sollten beim Bearbeiten aufpoppen, sobald sie in einer
Region vorhanden sind. Aktuell sind sie in JOSM allerdigns nicht mal
auswählbar, und daher dort gar nicht ersichtlich – Man muss also immer
zwischen mehreren Programmen hin-und-her-springen (oder gibt es eine
Option, die ich übersehen habe).

Ich bin mir sicher, dass Fehler, sobald sie für Mapper besser
ersichtlich sind, und sie für deren Behebung inklusive Behebungsvermerk
nicht zwischen mehreren Programm wechseln, und die Fehlermeldungen
separat anschalten müssen, auch (schneller) behoben werden.

Was externe Seiten mit Fehlermeldungen angeht: Ich melde Fehler in
Firefox ja auch nicht im LibreOffice-Bugtracker …

Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2013-07-21T15:29:24+0200


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wiki Nicht-Streitpunkt public_transport name/ref

Wilhelm Spickermann o...@spickermann-d.de wrote:

Im Proposal ist nicht ganz klar formuliert, worauf sich name und ref
beziehen. Aus der Recommendation im Proposal (steht auch im Wiki) geht
aber klar hervor, dass es sich auf den Bahnhofsnamen und nicht den
Gleis- oder Steignamen beziehen soll:

Wie kann man da jetzt vorgehen? Auf der Diskussionsseite was eintragen
führt augenscheinlich nicht zu Diskussionen.

Das scheint auch hier bisher nicht der Fall zu sein. Das Thema ÖPNV
wurde schon auf allen möglichen OSM Plattformen, Workshops und
Konferenzen bis zum Umfallen diskutiert, ohne dass sich bisher eine
durchsetzende Lösung ergeben hätte. Von daher ist man möglicherweise
des Themas müde geworden.

Immer mehr User äußern die Meinung, dass auch die Lösung laut Proposal
(auf Basis des ursprünglichen Oxomoa Schemas) gescheitert sei. 

IMHO liegt es daran, dass man zwar ein Schema gefunden hat, das
angeblich den informationstechnischen Aspekt bisher am optimalsten
abbildet. Allerdings hat man dabei vergessen, die Umsetzbarkeit durch
die Mehrheit der Mapper zu brücksichtigen. Daraus ergibt sich, dass
viele Bushaltestellen und folglich -Linien gar nicht oder in
unzähligen Varianten gemappt werden. 

IMHO sollte man zumindest für Busse die Trennung zwischen Plattform
und Stopstelle aufgeben. Im Allgemeinen wird eine Haltestelle in der
Wirklichkeit durch das Schild am Mast symbolisiert. Daher nimmt ihn
die Mehrheit der Mapper intuitiv auch als Haltestelle wahr. Auch wenn
ein ÖPNV Unternehmen eine Haltestelle versetzt, wird das
Haltestellenschild abgenommen und an anderer Stelle aufgestellt. Der
Bus hält dann einigermaßen lotrecht dazu auf der Straße. 

Man könnte diesen Vorgang 1:1 in OSM genau so abilden, indem man
diesen Mast mit dem guten alten highway=bus_stop mappt und für die
Stopstelle anwendungsseitig abhängig von Rechts- oder Linksverkehr ein
Lot auf die nächstliegende Straße fällt. Denn auch nach dem Proposal
wird bei einigermaßen gegenüber liegenden Haltestellen ohne
geometrische Überlegungen nicht deutlich, welche Stopstelle zu welcher
Plattform gehört. Warum dann bei diesen geometrischen Berechnungen
nicht einen Schritt weitergehen und gleich den Punkt selbst erzeugen?

Wenn dann nach diesem einfachen und umsetzbaren Schema die
Bushaltestellen von den vor Ort tätigen Mappern erfasst sind, kann sie
ein mehr überregional orientierter Mapper in die notwendigen
Relationen einsammeln.

Passiert dies in umgekehrter Reiehenfolge, in der der überegionale
Mapper zuerst ungefähr die Haltestellenorte abschätzt, kann sie der
örtliche Mapper leicht an die richtige Stelle schieben, ohne dass man
Gefahr läuft, die Stopstelle nun an dem falschen Ort zu haben.

Man könnte jetzt einwenden, dass die Stopstelle in wenigen
Ausnahmefällen an der falschen Stelle automatisch verortet werden
könne. Aber diese wenigen Fälle sind besser, als ein Chaos von nicht
oder uneinheitlich gemappten Haltestellen sowie abweichend voneinander
gelegenen Plattformen und Stopstellen.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wiki Nicht-Streitpunkt public_transport name/ref

Am 21. Juli 2013 16:03 schrieb Tirkon tirko...@yahoo.de:

 IMHO sollte man zumindest für Busse die Trennung zwischen Plattform
 und Stopstelle aufgeben. Im Allgemeinen wird eine Haltestelle in der
 Wirklichkeit durch das Schild am Mast symbolisiert. Daher nimmt ihn
 die Mehrheit der Mapper intuitiv auch als Haltestelle wahr. Auch wenn
 ein ÖPNV Unternehmen eine Haltestelle versetzt, wird das
 Haltestellenschild abgenommen und an anderer Stelle aufgestellt. Der
 Bus hält dann einigermaßen lotrecht dazu auf der Straße.

 Man könnte diesen Vorgang 1:1 in OSM genau so abilden, indem man
 diesen Mast mit dem guten alten highway=bus_stop mappt und für die
 Stopstelle anwendungsseitig abhängig von Rechts- oder Linksverkehr ein
 Lot auf die nächstliegende Straße fällt.



so machen wir es hier in der Gegend sowieso (die Stopstellen braucht man
glaube ich recht selten wirklich, normalerweise kann man die auch
automatisch projezieren). Wenn man sich das in taginfo ansieht, dann gibt
es fast 10x so viele highway=bus_stop als public_transport=platform oder
stop_position (und da sind noch alle anderen Verkehrsmittel auch dabei).

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Announce: Lokalisierung deutscher Kartenstil verbessert

Sven Geggus li...@fuchsschwanzdomain.de wrote:

aufgrund einer Anfrage auf der mapnik-de Mailingliste habe ich mal
das sehr rudimentäre Lokalisierungskonzept des deutschen Kartenstils
überdacht und deutlich verbessert.

Großartig, Sven! Endlich gibt es eine Karte, die man bei der OSM
Werbung auch weltweit vorzeigen kann. :-)

P.S.: Kann natürlich einen Moment dauern, bis alles aktualisiert ist.
Zum Neurendern einzelner tiles hilft der übliche /dirty Trick.

Und wie komme ich an die Adresse einer einzelnen Kachel, um /dirty
anhängen zu können?


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Announce: Lokalisierung deutscher Kartenstil verbessert

Am 21. Juli 2013 17:18 schrieb Tirkon tirko...@yahoo.de:

 Und wie komme ich an die Adresse einer einzelnen Kachel, um /dirty
 anhängen zu können?



Rechtsclick auf die Kachel und in neuen Fenster öffnen z.B. (je nach
verwendetem Betriebssystem und Browser geht das oder evtl. auch nicht),
sonst kannst Du auch in vielen Browsern die Medien-Elemente (sprich Bilder,
Videos etc.) auflisten lassen, und dort kopieren. Man kann auch aus den
Koordinaten und dem Zoomfaktor die Kacheladresse berechnen, aber das ist
eher was für Nerds ;-), wichtiger ist zu wissen, dass man immer gleich ein
Metatile dirty macht, d.h. 8x8 tiles.

Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Sinn und Unsinn von Fehlermeldungen (auf osm.org)

2013-07-21 Thread Bernd Wurst

Hallo.

Am 21.07.2013 14:42, schrieb Tirkon:
 Vielleicht ist aber Alles ganz anders. Dann wäre ich für eine
 Aufklärung recht dankbar, damit ich zukünftigen Beschwerdeführern eine
 bessere Antwort geben kann.

Also generell zum Sinn dieser Funktion: Es gibt Leute, die sehen dass da
was nicht stimmt, sind aber zu faul sich drum zu kümmern. Ob das jetzt
zeitweilig aktive OSM'ler sind oder nicht spielt keine Rolle. Besonders
wertvoll sind aber Gelegenheitsbesucher, die mit Mapping nix am Hut
haben. Wenn die die Seite weg klicken, sind die Leute weg, die kommen
nicht wieder. Das Wissen wollen wir trotzdem abgreifen, da es sehr
nützlich ist. Aber auch als Mapper hat man eben manchmal keine Lust nen
Finger krumm zu machen.
Daher so einfach wie nur irgend möglich, sprich: anonym ohne
Registrierung, direkt auf der Seite auf der auch die Karte angeschaut
wird. Das ist der Sinn. Die Integration auf der Hauptseite streben wir
seit zwei Jahren an, OSB war von Beginn an eine temporäre Lösung. Jetzt
ist es wohl so weit. ;-)


Die bisherigen Daten von OpenStreetBugs waren mit dem entsprechenden
JOSM-Plugin ständig verfügbar. Ich zoome auf eine Region, lade die
OSM-Daten herunter um zu mappen und sehe gleich auch die Bug-Reports,
die man dann ggf. beantworten kann. Wenn ich meine Heimat-Region in JOSM
lade, sehe ich auch gleich wenn jemand da einen Bug-Report eingetragen hat.
Es gibt OSB-Layer für die Garmin-Geräte und es gibt für diverse
Android-Apps die Möglichkeit, Bug-Reports anzuzeigen wo man grade vorbei
kommt.
(Ob das alles mit den Notes jetzt auch zuverlässig funktioniert weiß ich
noch nicht, ich hab das Thema seit ein paar Monaten stark vernachlässigt
und kenne den Status Quo nicht mehr.)


Klar gibt es Reports, die sind irgendwie wirr. Wenn man sich sicher ist,
dass ein Report für niemanden nützlich ist (in Skobbler auf die falsche
Fehlerkategorie geklickt?), dann macht man ihn halt zu und hofft, dass
jemand anderes den eigentlich gemeinten Fehler auch erkennt und klarer
meldet.

Es gibt auch Dinge die kann man durch einen Besuch vor Ort nicht lösen.
(Beispiel: Ich habe mehrere Quellen, dass sich an einer bestimmten
Stelle ein Weg mit einem bestimmten Namen befinden soll. Vor Ort habe
ich den Weg aber noch nicht gefunden. Da habe ich jetzt einen Bugreport
eingetragen und lass den da bis den jemand sieht, der sich dort besser
auskennt.)

Manche Regionen sind einfach auch zu weit weg für jeden von uns. In
manchen Regionen gibt es halt keine aktiven Mapper. Das ist dann Pech.

Solche Bugs bleiben länger in der DB, die anderen, normalen, lassen
sich meist schnell beheben.


In einem Punkt hast du und die anderen in diesem Thread Recht: Wenn es
mehrere Bug-Melde-Seiten und/oder keine Integration in die Editoren
gibt, ist das Konzept wertlos, da der Verwaltungsaufwand unermesslich
steigt. Dem ist aber nicht so, es gab bisher OSB (afaik wurden auch
skobbler-Bugs dorthin weiter geleitet) und nun ist das Konzept halt auf
die Hauptseite umgezogen und wenn das ordentlich funktioniert, wird OSB
dorthin weiter leiten. Und die Editor-Unterstützung, sofern nicht schon
vorhanden, wird es auch zügig geben, so wie bisher.

Gruß,
Bernd




signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Sinn und Unsinn von Fehlermeldungen (auf osm.org)

Tirkon wrote
Wenn sich ein OSMler in ein Gebiet begibt, um es mappen, dann...
Andererseits wird niemand zig Kilometer weit fahren, nur um einen
Bug zu klären. Für den Preis muss doch schon ein größeres Gebiet
flächendeckend herausspringen.

Auch nicht besser ist, zig Kilometer weit zu fahren um zu schauen ob sich
inzwischen etwas geaendert hat, nur um dann fest zu stellen, nein, alles ist
noch aktuell...

Wenn ein Land erst einmal erfasst ist, ist die Zeit in der ein Powermapper
mal eben ein groesseres Gebiet als Belohnung bekommt vorbei. Deshalb
braucht es fuer das aktuell halten der Daten ein vielfaches an mappern als
fuer die Ersterfassung benoetigt wurden. Dafuer braucht es dann die grosse
Masse an Leuten die vielleicht mal ein Fehler melden und dann nie wieder.
Eine der vielen mittle / gelegenheits mapper kann dann einen ein paar
hundert Meter weiten Umweg machen um ein spezifisches Problem das gemeldet
wurde zu ueberpruefen und zu korrigieren. Powermapper werden dann
hauptsaechlich armchair mapper werden die anderen helfen komplizierte
Relationen in Ordnung zu halten und schauen das nichts kaputt geht.

Natuerlich benoetigt es dafuer eine sehr hohe Dichte an (gelegenheits)
Mappern, aber anders ist das aktuell halten der Karte nicht wirklich
moeglich. Und fuer dieses Modell ist die Fehlermeldung auf osm.org imho sehr
wichtig und sinnvoll.

--
View this message in context:
http://gis.19327.n5.nabble.com/Sinn-und-Unsinn-von-Fehlermeldungen-auf-osm-org-tp5770713p5770749.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Announce: Lokalisierung deutscher Kartenstil verbessert

VielenDank für die schnelle Umsetzung. Ich war auch an lesbaren
Israelischen Karten interessiert. Gruß Johannes

Am Samstag, 20. Juli 2013 schrieb Sven Geggus :

Hallo zusammen,

aufgrund einer Anfrage auf der mapnik-de Mailingliste habe ich mal
das sehr rudimentäre Lokalisierungskonzept des deutschen Kartenstils
überdacht und deutlich verbessert.

Für den Anwender kommt dabei raus, dass folgende name-Tags in etwa
dieser Priorität auf der Karte gerendert werden:

name:de
name
int_name
name:en

Das Ganze geht natürlich nur, wenn man zusätzliche Annahmen trifft:

Es wäre zu Aufwendig, die Tatsache, dass sich ein Name im
deutschsprachigen Raum befindet mit einzubeziehen, stattdessen
schaut man einfach, ob der name Tag einen lateinischen Zeichensatz
hat und nur wenn das nicht der Fall ist wird ggf. int_name
oder name:en gerendert.

Getestet habe ich das Ganze mal in Chiang Mai wo die Karte jetzt
deutlich lesbarer geworden ist:
http://openstreetmap.de/karte.html?lat=18.79lon=98.98907zoom=13

Für die technisch interessierten:

Das Ganze ist über eine stored Procedure in PL/pgSQL gelöst:

http://svn.openstreetmap.org/applications/rendering/mapnik-german/views/get_germanified_name.sql

Das sieht beim Aufruf der Funktion dann so aus:

osm= select
get_germanified_name('Köln',NULL,'Col_int_ogne','Cologne') as name;
name
--
Köln
(1 Zeile)

osm= select get_germanified_name('เชียงใหม่',NULL,'Chiang Mai',NULL);
get_germanified_name
--
Chiang Mai
(1 Zeile)

Aufrufsemantik ist
get_germanified_name(name text, name_de text, int_name text, name_en text)

Jetzt bräuchte man nur noch eine passende Transliteration für
diverse große nicht-lateinische Alphabete z.B. für russisch.

Gruss

Sven

P.S.: Kann natürlich einen Moment dauern, bis alles aktualisiert ist.
Zum Neurendern einzelner tiles hilft der übliche /dirty Trick.

--
Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG)
umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und
Integrität
informationstechnischer Systeme. (BVerfG, 1BvR 370/07)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

___
Talk-de mailing list
Talk-de@openstreetmap.org javascript:;
http://lists.openstreetmap.org/listinfo/talk-de

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Thomas Reincke m...@thomas-reincke.de wrote:

On 11.07.2013 19:18, Toni Erdmann wrote:
 Meine Frage zielt auf:

 public_transport = stop_position
 public_transport = platform

 Haben die zusammen eine oder jeder seine eigene IFOPT-Nummern?

DE:5334:1001 ist die Nummer der Gesamthaltestelle, auch STOP genannt. 
Das passt etwas zu public_transport = stop_area

DE:5334:1001:1 ist die Nummer des Umsteigebereichs, auch AREA genannt. 
Das ist meist eine Zusammenfassung von Objekten mit ähnlichen 
Umsteigeeigenschaften. Achtung, es gibt auch bereichlsoe Haltestellen, 
dann wäre die Nummer DE:5334:1001:0.

DE:5334:1001:1:1 ist die Nummer des in EFA Steig genannten Objekt. Bei 
mir ist das der physikalische Mast. Englisch POINT.
Das passt zu einem punktförmigen public_transport = platform

Zu public_transport = stop_position gibt es m. E. nichts äquivalentes. 
Ich setze die stop_position meist auf das Lot des Mastes auf die Fahrbahn.

Das wäre dann ja inkompatibel zu dem Vorschlag von Tracy Kasperczyk

Zitat von Tracy Kasperczyk:
Für die Plattformen in OSM: de:Landkreisnr:lokale
Haltstellennummer:PlattformNr

Für die Stop_Position in OSM: de:Landkreisnr:lokale
Haltstellennummer:PlattformNr:SteigCode


Bei Dir (also beim Aachener Verkehrsverbund) entspricht Steig der
public_transport=platform, 
bei Tracy Kasperczyk entspricht Steig der
public_transport=stop_position.

Bei Dir ist die PlattformNr ungenutzt,
bei Tracy Kasperczyk entspricht die PlattformNr dem
public_transport=platform.

Du verwendest das Lot von Steig für public_transport=stop_position.
Die PlattformNr erfährt man bei Dir nicht.
 

Das geht ja überhaupt nicht zusammen, oder? Eine Anwendung kann doch
nicht zwischen dem Aachener Verkehrsverbund und beispielsweise dem
Nachbar Verkehrsverbund Rhein-Ruhr unterschiedlich interpretieren.
Denn einmal müsste sie beispielsweise den Steigcode vom
public_transport=platform-node/way und das andere Mal vom
public_transport=stop_position-node holen. 

Vom public_transport=platform-node/way erhält man einmal den Steigcode
und das andere Mal die PlattformNr.

Vom public_transport=stop_position-node erhält man einmal nichts und
das andere Mal den Steigcode.


Zitat von Tracy Kasperczyk:
Wir nehmen die Anregung von Stephan Wolff auf und ändern den Namen in
ref_ifopt

Benutzt Du auch ref_ifopt ?

Wenn diese Nummern bei OSM benutzt werden, wäre es doch sinnvoll, wenn
diese auch OSM-einheitlich verwendet werden.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten

2013-07-21 Thread Alexander Lehner



Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit 
hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen, 
Umleitungen, zusaetzliche amenities etc..


Das Thema wurde schon ein paar Mal angeschnitten. Gibt's da irgendwelche 
neuen Erkenntnisse?


OSM kann da ja durch seine Aktualitaet ziemlich punkten (vgl. Tsunami 
Karte), andererseits muss auch nicht jedes Kleingartenfest am Wochenende 
getagged werden.


A.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID) - bitte sofort stoppen

2013-07-21 Thread Michael Kugelmann


Am 19.07.2013 19:49, schrieb Wilhelm Spickermann:

Würdest Du bitte weniger irreführend zitieren?

Was ist bitte daran irreführend zitiert? Nichts!


Grüße,
Michael.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wiki Nicht-Streitpunkt public_transport name/ref

Wilhelm Spickermann o...@spickermann-d.de wrote:

Ok, was solls, ich hab gerade auf meiner Wikiseite mal das Pre-Draft für
ein Public Transport Amendment zum Abschuss freigegeben.

Wilhelm (Weide, http://wiki.openstreetmap.org/wiki/User:Weide)

Sieht auf den ersten Blick ganz gut, konsistent und einfacher als das
jetzige Proposal aus. Was mir bisher aufgefallen ist:

Bei Bahnsteigen mit Gleisen auf beiden Seiten wird nicht klar, auf
welcher Seite der Fahrgast seine Bahn zu erwarten hat.

Die Values für Komplettheit müssten noch einen Wert für fraglich
zulassen, möglicherweise ?.

To be able to map platform nodes with unknown properties, the tag 
public_transport=any_platform is added to the set of values. This tag 
corresponds to highway=bus_stop and alike even in the case of nodes. 
For ways and areas it's the same as public_transport=platform.

Verstehe ich nicht. Was sagt public_transport=any_platform aus? Und
zu welcher Menge von Werten wird das hinzugefügt. (eventuell Beispiel)
Der Key public_transport kann doch nur einen Wert haben. Und wann
wird stattdessen highway=bus_stop oder public_transport=platform
getaggt. Was passiert dann mit der erwähnten Menge von Werten? 

pt2_subname A name as found on the splot ...
Die Bedeutung der Vokabel splot konnte ich nicht ergründen.

pt2_subname=? value is unknown, but there is one

pt2_subname omitted: unknown
Wo ist der Unterschied zwischen den beiden Alternativen? Weiß ich beim
der zweiten weder den Wert, noch dass ein Wert existiert?


Other tags traditionally used in such relations (like network, 
operator, ...) may of course be used. 
Network wäre hier wohl zwingend, da es in jedem Verkehrverbund Linien
mit der gleichen Nummer geben kann. Ich weiß nicht, ob wir auch noch
ein DE (respektive andere Länderkennung) brauchen, da möglicherweise
ein gleichlautendes Network im Ausland existieren könnte. 

vehicle The vehicle kind(s) used. 
Vehicle macht mir etwas Bauchschmerzen, weil es von der Acess
Wikiseite stammt, die ihrerseits inkonsistent ist. Geht aber
vermutlich.

*_exit_only and role : *_entry_only are not really useful as first 
and last stop markers and for intermediate stops they are not 
needed as time table routing doesn't use them.
Hmm, man sollte aber schon wissen, dass man an einer Haltestelle nicht
einsteigen kann - insbesondere wenn es nicht die letzte ist.


Variants - Member roles
haltvar bis part+ sind Rollen von ways der Route, halt sowie +halt
sind Rollen von nodes der Haltestellen. Ist das richtig? Wenn ja,
könnte das im Text - eventuell durch Überschriften - noch
verdeutlichst werden.


Ich fasse das Ganze für eine einfache Standard-Buslinie ohne Varianten
in Kurzform zusammen. Wir packen die Haltestellen und die Route pro
Fahrtrichtung in dieser Reihenfolge und in Fahrtrichtung sortiert in
jeweils eine Relation: type=pt2, pt2=variant. Die beiden sich
ergebenden Relationen kommen wieder in eine Elternrelation: type=pt2,
pt2=master. Richtig?

Was mir unklar bleibt: Wie weiß man jetzt, wo ein Umsteigepunkt zu
einer ebenso einfach gestrickten Linie besteht, wenn Du die stop_area
abschaffst?

Zuletzt: Was mir die größten Bauchschmerzen bereitet, ist das
parallele Existieren derselben Linien in zwei Relationsmodellen. Das
könnte für die Mapper verwirrender nicht sein. 

Nach den letzten Reinfällen würde ich für eine konzertierte Aktion
aller Beteiligten und der Foundation plädieren, die nach entsprechend
guter Vorbereitung einen relativ harten Schnitt macht. Dabei sollte
der Umstellungszeitpunkt schon zuvor auf jeder Seite des Wikis, auf
osm.org und möglicherweise per E-Mail angekündigt werden. Zu der guten
Vorbereitung sollte dann auch gehören, dass diesmal eine möglichst
breite Masse der Community gebeten wird, Stellung zu beziehen und die
wasserdichte Konsistenz abklopft. Die existierenden ÖPNV Karten
sollten das neue Schema zum Zeitpunkt der Umstellung schon
unterstützen. Es sollten möglichst eine Videoanleitung,
aussagekräftige Beispielgrafiken, eine beispielhaft gemappte Region in
OSM und vielleicht auch ein Editor-PlugIn existieren. Alle User werden
aufgerufen, bevorzugt an der schnellen Umstellung der nach dem alten
Proposal gemappten Linien ab dem angekündigten Termin mitzuwirken.
Möglicherweise kann man dabei mit Bots arbeiten, wobei der Bot schon
im Vorfeld abklopfen könnte, was botgestützt umgestellt werden kann.
Es hat keinen Sinn, wenn das letzte Fiasko noch einmal wiederholt
wird. Diesmal muss es einfach gelingen. 

Bin jetzt zu müde und muss mir das noch einmal ausgeschlafen
anschauen.

Vielen Dank für Deinen Arbeitsaufwand, den Du in das Proposal gesteckt
hast.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-21 Thread Michael Kugelmann


Am 18.07.2013 19:42, schrieb Dirk Sohler:

Man, man, man, müssen wir denen jetzt auch noch hinterherrennen, und
die von ihnen eingebauten, ihren Zwecken dienlichen, Fehler in OSM
wieder korrigieren?
Jetzt bleib bitte auf dem Teppich! Konstruktiv arbeiten und nicht nur 
rumjammern.


Um mal etwas allgemeiner zur Diskussion zu schreiben:
dIe Leute waren mehrfach auf dem Stammtisch in München um Kontakt mit 
der Community aufzunehmen und um Rat zu fragen. Also Vorwürfe von wegen 
die machen alles kaputt und das dient nur einem kommerziellen 
Interesse etc. sind sehr an den Haaren herbeigezogen: die wollen 
wirklich zusammen mit der OSM-Community etwas sinnvolles machen und 
nicht dagegen. (BTW: ich finde das ähnlich zu ein paar anderen 
aktuellen  weltfremde Diskussionen!). Und dass ein kommerzielles 
Unternehmen Community erst lernen muss ist verständlich. Insbesondere 
denke ich, dass die OSM-Community teilweise noch etwas spezieller ist, 
als manche andere FLOS-Community. Für mich ist es nicht verwunderlich, 
dass dabei an der Schnittstelle durch unglückliche Aktionen unnötige 
Reibereien entstehen. Ich kann nur zur Mäßigung - insbesondere 
innerhalb  der Community - aufrufen.
Gleich noch dazu gesagt: die Triebfeder für die mögliche Nutzung der 
OSM-Daten kommt nicht nur aus der Firma (sondern z.B. den 
Verkehsverbünden). Und an statt dass sich die Community freut, dass mit 
den OSM-Roh-/Vektor-DATEN etwas sinnvolles gemacht werden soll wird (von 
einigen) nur rumgejammert: ohhh, der Nachbar hat an meiner schönen 
Sandburg etwas verändert und dazu mein Förmchen benutzt. Denkt doch mal 
bitte nach: bis jetzt werden die OSM-Daten vor allem als 
schnöde/primitive Karte genutzt. Hier bietet sich die Chance, dass die 
OSM-Daten im großen Stil als Roh-/Vektor-Daten verwendet werden. Und 
dabei werden noch die Daten verbessert, was wollt ihr denn mehr...
Noch etwas: das Ganze ist ja von Europa getrieben (EU-Kommision oder 
EU-Rat oder so) = ihr könnt Euch als in Brüssel beschwerden...


Ach ja: gleich noch ein Mantra mit aufzunehmen: wir mappen nicht für die 
Karte. Wenn der Renderer etwas falsch darstellt, dann hat der Renderer 
angepasst zu werden und nicht die Daten schlecht gemacht zu werden dass 
es gut aussieht. Daran erinnern mich auch ein paar Diskussionen...



Grüße,
Michael.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Gebäudenummern auf Firmengelände

Hallo,

wie taggt man eine interne Gebäudenummer eines größeren Firmenareals, die
keine amtliche Hausnummer ist?

Grüße Johannes
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] OSM Radio Live Folge 19

Hallo, wo kann man die Live-Folge nur 19 von letzter Woche hören?

Gruß Johannes
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar

Hallo Dietmar,

die Kölner Stadtbezirke und Stadtteile (vollständig) hatte ich letztes Jahr
importiert. Wenn keine Relation kaputtgemacht wurde, stimmt das noch.

Gruß Johannes

Am 19. Juli 2013 22:48 schrieb Dietmar ostr...@diesei.de:

 Generell können evtl. noch Stadtbezirke oder Teilbezirke fehlen, das habe
 ich in Köln nicht geprüft, in München fehlen noch 4 Bezirke, die ich
 angepasst habe in OSM sowie einige Teilbezirke (3 fehlen in München noch).
 Die werden dann nicht aufgeführt, wenn bei denen boundary=administrative
 fehlt.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID) - bitte sofort stoppen

2013-07-21 Thread Wilhelm Spickermann

Am Mon, 22 Jul 2013 02:19:11 +0200
schrieb Michael Kugelmann michaelk_...@gmx.de:

 Am 19.07.2013 19:49, schrieb Wilhelm Spickermann:
  Würdest Du bitte weniger irreführend zitieren?
 Was ist bitte daran irreführend zitiert? Nichts!

Wenn mein Name oben drüber steht und dann nur Text kommt, der nicht
von mir ist, dann ist das irreführend. 

Wilhelm

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-it] Riferimento distributori di benzina

2013-07-21 Thread bredy

quindi eliminiamo se ho ben capito anche quelli già presenti



--
View this message in context: 
http://gis.19327.n5.nabble.com/Riferimento-distributori-di-benzina-tp5770620p5770694.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] end_farm

2013-07-21 Thread bredy

sarò anche stupido, ma sulla pagina non c'è scritto di non usare farm.

se non bisogna più usarlo va specificato deprecated, ma se non lo han fatto
nel sito inglese mi par strano a mio avviso è ancora valido.

comunque grazie al sito segnalato son riuscito a modificare tutti i miei tag
farm in farmland senza tanta fatica in breve tempo.



--
View this message in context: 
http://gis.19327.n5.nabble.com/landuse-tp5766839p5770695.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] end_farm

2013/7/21 bredy bredy...@yahoo.it

 se non bisogna più usarlo va specificato deprecated, ma se non lo han fatto
 nel sito inglese mi par strano a mio avviso è ancora valido.



è stato deprecato più di una volta ;-) Ma non c'è un consenso univoco,
quindi ciò che si vede nel wiki come spesso è un compromesso. Siamo
comunque noi a determinare quale direzione i tags prendono (col nostro
uso).

Anche se quel tag fosse segnalato come deprecato non significherebbe che
è vietato usarlo...
Personalmente sono a favore di farmland, perché i problemi di farm sono
reali, e farmland è l'evoluzione di farm.

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Possibilità di import dati Umbria?

2013-07-21 Thread Marcello Arcangeli

Grazie Giuseppe delle informazioni, seguo sempre la lista di discussione
e ho un'idea della prassi amministrativa, ma sono ignorante dal punto di
vista del processo tecnico, per cui non ho intenzione di fare un import
selvaggio.
L'Umbria è mappata molto a macchia di leopardo, considera che abito in
una cittadina di 10.000 abitanti e fino a fine gennaio (quando ho
scoperto OpenStreetMap) c'erano solo la primary e 2 secondary che
l'attraversano un altro paio di vie (senza nome) e null'altro, per cui
sicuramente non ci sarebbe sovrabbondanza.
Data la mia ignoranza in fatto di import chiedo se qualcuno con un po'
di esperienza nel campo può verificare la fattibilità dell'import dei
dati disponibili dal punto di vista tecnico, poi ne discuterei con la
comunità vantaggi/svantaggi e se si decide che potrebbe essere
vantaggioso partirei con la richiesta di autorizzazione (sempre con i
suggerimenti di qualcuno più esperto).

Ciao,
Marcello

Il giorno sab, 20/07/2013 alle 19.34 +0200, Giuseppe Bilotta ha scritto:
 2013/7/20 Marcello Arcangeli arca...@gmail.com:
  Data la situazione pensate, se tecnicamente fattibile, sia il caso di
  richiedere l'autorizzazione per un eventuale utilizzo o import ed
  eventualmente come si deve procedere?
  Grazie
  Marcello
 
 Non so se sia il caso o meno (non ho visto quanto sono dettagliati i
 dati present in OSM per l'Umbria. Riguardo al cosa fare, direi che c'è
 da (1) chiedere l'autorizzazione alla regione umbria [ovviamente] (2)
 discutere con gli admin OSM a proposito dell'import.
 Da quanto ho visto discusso su #osm, un'attività di bulk import non
 autorizzata è generalmente mal vista e può portare anche al ban
 dell'account OSM. In genere per queste attività viene riservato un
 account apposito, ed il lavoro viene fatto in prima passata su un
 database di sviluppo distinto da quello principale. Raccomando una
 lettura di http://wiki.openstreetmap.org/wiki/Import/Guidelines per
 qualche informazione supplementare. (Ovviamente, gente che ha già
 fatto bulk import avrà maggiori informazioni da darti.)
 
 
 --
 Giuseppe Oblomov Bilotta
 
 



___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Riferimento distributori di benzina

2013-07-21 Thread Andrea Musuruane

I dati frutto dell'import originario vanno mantenuti, quelli aggiunti
successivamente devono essere rimossi.

Ciao,

Andrea.
Il giorno 21/lug/2013 10:59, bredy bredy...@yahoo.it ha scritto:

 quindi eliminiamo se ho ben capito anche quelli già presenti



 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Riferimento-distributori-di-benzina-tp5770620p5770694.html
 Sent from the Italy General mailing list archive at Nabble.com.

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-it

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Riferimento distributori di benzina



On 21/lug/2013, at 13:07, Andrea Musuruane musur...@gmail.com wrote:

 I dati frutto dell'import originario vanno mantenuti,


se prezzi benzina adesso ha una licenza proprietaria toglierei i riferimenti al 
loro db quando modifico per un altro motivo un oggetto.

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Riferimento distributori di benzina

2013-07-21 Thread bredy

comunque il codice punto vendita non è proprietario di prezzibenzina.it, ma
si ricavano dai siti degli operatori, quindi si potrebbero inserire come
ref, se non si può mettere il riferimento a www.prezzibenzina.it



--
View this message in context: 
http://gis.19327.n5.nabble.com/Riferimento-distributori-di-benzina-tp5770620p5770710.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] Routing marittimo per Bastia

2013-07-21 Thread Carlo Stemberger


Buongiorno,
qualcuno riesce a capire perché il routing da Livorno funzioni, mentre 
da Nizza e da Genova no?


http://osrm.at/4lq

Grazie!

Carlo

--
  .-.  | Registered Linux User #443882|  .''`.
  oo|  | http://linuxcounter.net/ | : :'  :
 /`'\  |   Registered Debian User #9  | `. `'`
(\_;/) | http://debiancounter.altervista.org/ |   `-


___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Riferimento distributori di benzina



On 21/lug/2013, at 14:00, bredy bredy...@yahoo.it wrote:

 comunque il codice punto vendita non è proprietario di prezzibenzina.it, ma
 si ricavano dai siti degli operatori,


o forse anche dallo scontrino?

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Routing marittimo per Bastia

2013-07-21 Thread Carlo Stemberger


Ho aperto un ticket:

https://github.com/DennisOSRM/Project-OSRM/issues/676

Carlo

--
  .-.  | Registered Linux User #443882|  .''`.
  oo|  | http://linuxcounter.net/ | : :'  :
 /`'\  |   Registered Debian User #9  | `. `'`
(\_;/) | http://debiancounter.altervista.org/ |   `-


___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Possibilità di import dati Umbria?

2013-07-21 Thread Paolo Monegato


Il 20/07/2013 11:58, Marcello Arcangeli ha scritto:

I termini di utilizzo sono i seguenti:
I Servizi possono essere usati liberamente per uso locale di studio e
di ricerca. Non possono essere utilizzati per attività commerciali. In
caso di necessità di pubblicazione e/o altri utilizzi occorre richiedere
apposita autorizzazione alla Regione Umbria - Servizio
Informatico/Informativo: geografico, ambientale e territoriale. In ogni
caso nelle elaborazioni deve essere sempre riportata la fonte dei dati.


Mi sembra che i termini d'utilizzo non siano compatibili con OSM, quindi 
non occorre perdere tempo per capire se è fattibile tecnicamente...


ciao
Paolo M

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] end_farm

2013-07-21 Thread Mario Pichetti


Il 21/07/2013 11:18, Martin Koppenhoefer ha scritto:


2013/7/21 bredy bredy...@yahoo.it mailto:bredy...@yahoo.it

se non bisogna più usarlo va specificato deprecated, ma se non lo
han fatto
nel sito inglese mi par strano a mio avviso è ancora valido.



è stato deprecato più di una volta ;-) Ma non c'è un consenso univoco, 
quindi ciò che si vede nel wiki come spesso è un compromesso. Siamo 
comunque noi a determinare quale direzione i tags prendono (col nostro 
uso).


Anche se quel tag fosse segnalato come deprecato non significherebbe 
che è vietato usarlo...
Personalmente sono a favore di farmland, perché i problemi di farm 
sono reali, e farmland è l'evoluzione di farm.


ciao,
Martin


___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it



Il bello di OSM è proprio questo, le regole sono finalizzate ad una 
evoluzione armonica e positiva.


Le regole non devono ostacolare, ma migliorare il processo.

In background, una comunità mondiale è in continuo movimento e 
perfeziona divertendosi.


Non esiste un limite al miglioramento, OSM è una lingua che si evolve 
nel tempo.


OSM, non è solo editor e tag, ma molto di piùe si espande:-)

Ciao, Mario.



___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Copyright

2013-07-21 Thread Aury88

No, non sto scherzando...da dove deriverebbero i milioni di costi? qui non
servono studi scientifici o indagini fatte da esperti o periti. basta un
avvocato (e la OSMF so che ne ha alcuni non so se in busta paga o se sono
volontari che offrono il proprio servizio ).
e comunque, come già detto, ad un'azienda vincere la causa contro osm non
converrebbe visto che creerebbe un precedente sfruttabile dalla concorrenza
per violare brevetti e copyright appartenenti all'azienda stessa (e tutto
per cosa? per usare una mappa?)...
a che mi risulta la Apple ha messo un link con elencati tutti i fornitori
delle mappe tra le quali figura anche la OpenStreetMapsia per l'iphoto sia
per le mappe come confermato  qui
http://www.iphoneitalia.com/apple-accredita-ufficialmente-openstreetmap-per-le-mappe-incluse-in-iphoto-371431.html
  
e  qui http://blog.osmfoundation.org/2012/10/02/apple-maps/  .



--
View this message in context: 
http://gis.19327.n5.nabble.com/Copyright-tp5770343p5770746.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Copyright

2013/7/21 Aury88 spacedrive...@gmail.com

No, non sto scherzando...da dove deriverebbero i milioni di costi? qui non
servono studi scientifici o indagini fatte da esperti o periti. basta un
avvocato (e la OSMF so che ne ha alcuni non so se in busta paga o se sono
volontari che offrono il proprio servizio ).

uno l'avvocato si prende l'onorario a secondo del valore in causa e due
l'avversario potrebbe fare una causa per danneggiamento della reputazione.

e comunque, come già detto, ad un'azienda vincere la causa contro osm non
converrebbe visto che creerebbe un precedente sfruttabile dalla concorrenza
per violare brevetti e copyright appartenenti all'azienda stessa

no, loro non usano quasi mai licenze come la nostra.

a che mi risulta la Apple ha messo un link con elencati tutti i fornitori
delle mappe tra le quali figura anche la OpenStreetMapsia per l'iphoto sia
per le mappe come confermato qui

http://www.iphoneitalia.com/apple-accredita-ufficialmente-openstreetmap-per-le-mappe-incluse-in-iphoto-371431.html

e qui http://blog.osmfoundation.org/2012/10/02/apple-maps/ .

Quali dati sono da OSM e qual'è la licenza? E perché a noi non riconoscono
il copyright (© OSM contributors come richiesto) mentre altri fornitori
hanno un © davanti? Solo i dati di dominio pubblico non hanno un © davanti
all'attribuzione nella loro lista.
Comunque, sia la ODbL che la cc-by-sa 2.0 unported richiedono che la
licenza viene indicata. Se non viene indicata non è possibile determinare i
diritti che ne risultano (come anche non è possibile se non sai quali sono
i dati derivanti da OSM).

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Routing marittimo per Bastia

2013-07-21 Thread Giacomo Boschi

Una prima risposta potrebbe essere che il routing assegna un peso esagerato
alle rotte via mare, che obbliga l'algoritmo a preferire sempre la tratta
su traghetto più corta. Infatti se provo a fare il viaggio da molo a molo
ottengo quasi 24 ore per 120 chilometri.


2013/7/21 Carlo Stemberger carlo.stember...@gmail.com

 Ho aperto un ticket:

 https://github.com/DennisOSRM/**Project-OSRM/issues/676https://github.com/DennisOSRM/Project-OSRM/issues/676


 Carlo

 --
   .-.  | Registered Linux User #443882|  .''`.
   oo|  | http://linuxcounter.net/ | : :'  :
  /`'\  |   Registered Debian User #9  | `. `'`
 (\_;/) | 
 http://debiancounter.**altervista.org/http://debiancounter.altervista.org/| 
   `-


 __**_
 Talk-it mailing list
 Talk-it@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-ithttp://lists.openstreetmap.org/listinfo/talk-it




-- 
-- 
Giacomo Boschi
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Routing marittimo per Bastia

2013-07-21 Thread Edoardo Yossef Marascalchi

esiste un tag per definire cadenza e durata della tratta? anche fosse
veloce ma percorsa solo 2 volte al giorno potrebbe non essere la migliore
On Jul 21, 2013 11:18 PM, Carlo Stemberger carlo.stember...@gmail.com
wrote:

 Ciao Giacomo,

 Il giorno 21 luglio 2013 19:58, Giacomo Boschi gwil...@gmail.com ha
 scritto:

 Una prima risposta potrebbe essere che il routing assegna un peso
 esagerato alle rotte via mare, che obbliga l'algoritmo a preferire sempre
 la tratta su traghetto più corta.


 Sì, in effetti questa è l'unica spiegazione sensata...

 In effetti non è un'idea del tutto sbagliata, considerando che le navi
 viaggiano lentamente (i traghetti, che sono molto molto veloci, viaggiano
 attorno ai 50 km/h), e che l'unico algoritmo al momento disponibile su OSRM
 è Macchina (più veloce).

 Si tratta comunque di un limite di OSRM: non è possibile forzare una rotta
 a scelta, dato che non si possono posizionare marker sulle rotte navali.

 Buona serata!

 Carlo

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-it


___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-ro] România în limbi străine

2013-07-21 Thread andrewuaic

Numele german echivalent denumirii orasului Barlad nu poate fi gasit in nici
o referinta pe google. Poti confirma denumirea Bariach pentru Barlad ?



--
View this message in context: 
http://gis.19327.n5.nabble.com/Romania-in-limbi-str-ine-tp5770754p5770767.html
Sent from the Romania mailing list archive at Nabble.com.

___
Talk-ro mailing list
Talk-ro@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro

Re: [Talk-ca] Canvec-OSM FTP Down?

2013-07-21 Thread Daniel Begin

The links in the wiki (Canvec) is now corrected

Daniel

From: François Paquette [mailto:fpaque...@cooptel.qc.ca] 
Sent: July-20-13 18:18
To: 'Daniel Begin'; 'Adam Dunn'; 'talk-ca'
Subject: RE: [Talk-ca] Canvec-OSM FTP Down?

Try with

 http://ftp2.cits.rncan.gc.ca/OSM/pub http://ftp2.cits.rncan.gc.ca/OSM/pub

The FTP site is case sensitive

François

De : Daniel Begin [mailto:jfd...@hotmail.com] 
Envoyé : 20 juillet 2013 18:12
À : 'Adam Dunn'; 'talk-ca'
Objet : Re: [Talk-ca] Canvec-OSM FTP Down?

Bonjour Adam,

I tried to access the site about a week ago without success. I was hoping
the problem was temporary but I now worried

Daniel

From: Adam Dunn [mailto:dunna...@gmail.com] 
Sent: July-20-13 15:46
To: talk-ca
Subject: [Talk-ca] Canvec-OSM FTP Down?

Just tried to download a tile from http://ftp2.cits.rncan.gc.ca/osm/pub and
the server is saying the directory doesn't exist. Hopefully just a temporary
thing, but does anybody know what's going on?

Adam

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] Rôtisserie ?

Le 20/07/2013 19:07, Philippe Verdy a écrit :
 C'est une catégorie de boucherie, non ?
 
 shop=butcher
 butcher=poultry
 
 Certes cela n'indique pas que la volaille est vendue rôtie et non prête à
 cuire. Mais bien peu de rôtisseries ne vendent que la volaille cuite, et la
 plupart des endroits où on vend la volaille la proposent aussi rôtie.
 

Une rôtisserie est un commerce où l'on vend des poulets cuits (rôtis)
mais pas crus [1]. Donc, amha, les tags que tu proposes ne sont pas
adaptés, même si moi-même je n'ai pas d'idée.


[1] en général c'est l'inverse : quand tu as affaire avec un poulet,
c'est lui qui est cru et toi qui es cuit.
-- 
Jean-Francois Nifenecker, Bordeaux

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Josm : 2 instances ?

2013-07-21 Thread Hélène PETIT

Je ne sais pas s'il est possible de lancer deux instances de josm en
même temps ?
Par exemple pour travailler sur deux régions différentes, avec des
contextes différents ?


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Osmose] Nouveautés

Le 20/07/2013 14:52, Frédéric Rodrigo a écrit :
 Bonjour,
 
 Voilà les dernières nouveautés d'Osmose :
 
 Adresse manquante : support de Lyon et de Montpellier
 http://osmose.openstreetmap.fr/fr/map/?item=8080level=1,2,3
 
 Intégration des gares depuis le GTF de la SNCF
 http://osmose.openstreetmap.fr/fr/map/?item=7100,8050,8051level=1,2,3
 
 Détection des géométries dupliqués (merci à Didier2020 pour cette
 nouvelle analyse)
 http://osmose.openstreetmap.fr/fr/map/?item=1230level=1,2,3
 
 Distinction des pharmacies et des parapharmacies ou autres
 http://osmose.openstreetmap.fr/fr/map/?item=2100level=1,2,3
 
 Le Quality Assurance Tools script pour JOSM supporte Osmose. Cet outil
 ajoute un menu à JOSM qui permet de télécharger un type d'erreur pour la
 zone courante depuis divers outils qualité.
 http://wiki.openstreetmap.org/wiki/Quality_Assurance_Tools_script
 
 Il est désormais possible de traduction le backend d'Osmose en utilisant
 simplement un fichier .po. La traduction en espagnol des erreurs est
 maintenant disponible.
 https://gitorious.org/osmose/backend/trees/master/po
 À noter que les mêmes langues ne sont pas disponible pour le backend et
 le frontend.
 
 Les erreurs osmose on été taggué pour déterminer une méthode de
 correction approprié :
 La liste des tags : http://osmose.openstreetmap.fr/fr/api/0.2/meta/tags
 Les nouveau tags sont fix:chair, fix:imagery et fix:survey il peuvent
 être ajouté aux urls d'Osmose tags=fix:survey par exemple.
 
 Suite à des problèmes de longueur de calcul la fréquence de mise à jour
 d'Osmose était passé de 48h à 72h. Suite à de l'optimisation l'on a pu
 repassé à 48h. Coté serveur également, la partie web à été déplace du du
 vénérable serveur osm1 mourant à un serveur chez Free.
 
 Et pour finir un nouveau pays en langue anglaise : New-zealand, pour
 espérer commencer la localisation des analyses à l'anglais ou les rendre
 plus génériques.
 

Bravo et merci !

j'ai cependant un regret (pas lié aux modifications présentées ici), à
propos des tags oneway=yes.

Depuis qq temps, Osmose groupe cette détection oneway=* :
(1) superflus sur les junction=roundabout.
(2) manquants sur les contre-sens cyclables

C'est très gênant lorsque l'on ne recherche qu'un seul type d'erreur (ex
pratique : je fais régulièrement des vérifs sur les ronds-points).
D'autant que l'erreur (2) peut difficilement être corrigée sans visite
sur le terrain alors que l'erreur (1) peut l'être pour la valeur yes.

Serait-ce possible de dégrouper ces deux détections ?

Merci encore pour le gros boulot de QA réalisé !
-- 
Jean-Francois Nifenecker, Bordeaux

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Multi-polygone

2013-07-21 Thread mides.map





Bonjour, 

tout d'abord, merci pour tous ces conseils.

Concernant les frontires administratives, en gnral, j'vite de les
dplacer et si chevauchement de chemins, je privilgie les segments
River, highway, etc.

Pour ce qui est de la richesse du trac : doit on allger, dans la
mesure du raisonnable, ou faire au plus fin ? 

Effectivement, il serait bon de rajouter quelques infos du style : lien
Wikipedia, navigabilit ou autres, mais je suppose que ces dernires
doivent tre apportes sur le waterway:river et non pas
waterway:riverbank.

Dans le cas d'un ilot, quel axe privilgier concernant le trac du
waterway:river, je suppose qu'il ne peut y en avoir un de chaque cots ?

Et pour terminer, merci pour la syntaxe permettant de forcer le
rafraichissement des dalles, un me semble l'avoir dj vu quelque part
mais il va de soi que l'avais oubli aussi. ;-)

En vous souhaitant un bon dimanche au soleil.

Michel

hamster a crit:

  Le 21/07/2013 00:39, Yves Pratter a crit :
  
  
La difficults ici c'est que les frontires administratives suivent
cette ligne. Il faut soit accepter de les dplacer ??

  
  
oh non, certainement pas

  
  
soit faire deux
chemins distincts, un pour la rivire, un autre pour les frontires.

  
  
c'est bien mieux comme ca oui

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
.

  






___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Osmose] Nouveautés

2013-07-21 Thread Christian Quest

Tu peux personnaliser l'URL d'osmose pour réduire à un item et une
class(e), exemple:

http://osmose.openstreetmap.fr/fr/map/?item=2030class=20301 (manque
oneway sur cycleway=opposite)



Le 21 juillet 2013 08:26, Jean-Francois Nifenecker
jean-francois.nifenec...@laposte.net a écrit :

 Bravo et merci !

 j'ai cependant un regret (pas lié aux modifications présentées ici), à
 propos des tags oneway=yes.

 Depuis qq temps, Osmose groupe cette détection oneway=* :
 (1) superflus sur les junction=roundabout.
 (2) manquants sur les contre-sens cyclables

 C'est très gênant lorsque l'on ne recherche qu'un seul type d'erreur (ex
 pratique : je fais régulièrement des vérifs sur les ronds-points).
 D'autant que l'erreur (2) peut difficilement être corrigée sans visite
 sur le terrain alors que l'erreur (1) peut l'être pour la valeur yes.

 Serait-ce possible de dégrouper ces deux détections ?

 Merci encore pour le gros boulot de QA réalisé !


-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Josm : 2 instances ?

2013-07-21 Thread Vincent de Château-Thierry


Bonjour,

Le 21/07/2013 08:34, Jean-Francois Nifenecker a écrit :

Le 21/07/2013 08:18, Hélène PETIT a écrit :

Je ne sais pas s'il est possible de lancer deux instances de josm en
même temps ?


Yaka essayer ;-P

Et, pour moi ça a l'air de marcher (Debian Weezy, Josm 5267, Java
1.6.0.27). Bon, j'ai pas testé bien loin mais j'ai pu charger deux zones
très différentes de France sans pb.

Bon week-end au frais :)


Oui ça fonctionne, mais seule la première instance activera la 
telecommande (Remote Control): ce qui permet de jouer avec Osmose  co.


vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Osmose] Nouveautés

Le 21/07/2013 08:43, Christian Quest a écrit :
 Tu peux personnaliser l'URL d'osmose pour réduire à un item et une
 class(e), exemple:
 
 http://osmose.openstreetmap.fr/fr/map/?item=2030class=20301 (manque
 oneway sur cycleway=opposite)
 

Yay! \o/

Merci Christian ! Les outils sont *encore* meilleurs que je le pensais ;)
-- 
Jean-Francois Nifenecker, Bordeaux

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Josm : 2 instances ?

Le 21/07/2013 08:18, Hélène PETIT a écrit :
 Je ne sais pas s'il est possible de lancer deux instances de josm en
 même temps ?

Yaka essayer ;-P

Et, pour moi ça a l'air de marcher (Debian Weezy, Josm 5267, Java
1.6.0.27). Bon, j'ai pas testé bien loin mais j'ai pu charger deux zones
très différentes de France sans pb.

Bon week-end au frais :)
-- 
Jean-Francois Nifenecker, Bordeaux

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Multi-polygone

2013-07-21 Thread Christian Quest

Le 21 juillet 2013 08:29, mides.map mides@gmail.com a écrit :
 Bonjour,

 tout d'abord, merci pour tous ces conseils.

 Concernant les frontières administratives, en général, j'évite de les
 déplacer et si chevauchement de chemins, je privilégie les segments River,
 highway, etc.


Dans le cas présent vu la copie d'écran, on dirait bien que la limite
administrative et le tracé de la rivière sont superposés.
C'est pour moi la pire solution... difficile de sélectionner l'un et
pas l'autre, lorsqu'on sélectionne la rivière on ne voit pas forcément
que les mêmes nœuds portent une limite administrative, etc, etc.



 Pour ce qui est de la richesse du tracé : doit on alléger, dans la mesure du
 raisonnable, ou faire au plus fin ?


Si tu as une source précise, autant être précis, non ?


 Effectivement, il serait bon de rajouter quelques infos du style : lien
 Wikipedia, navigabilité ou autres, mais je suppose que ces dernières doivent
 être apportées sur le waterway:river et non pas waterway:riverbank.


Tout à fait. Le riverbank sert à avoir l'emprise du cours d'eau, le
filaire modélise lui la voie de communication, le sens d'écoulement,
etc.


 Dans le cas d'un ilot, quel axe privilégier concernant le tracé du
 waterway:river, je suppose qu'il ne peut y en avoir un de chaque cotés ?


Si bien sûr, il peut y en avoir un de chaque côté. Il peut même y
avoir un sens de circulation avec un oneway pour l'indiquer.


 Et pour terminer, merci pour la syntaxe permettant de forcer le
 rafraichissement des dalles, un me semble l'avoir déjà vu quelque part mais
 il va de soi que l'avais oublié aussi. ;-)


Il faut récupérer l'adresse d'une tuile (clic droit), puis tu rajoute
/dirty à la fin de l'URL, exemple:
http://b.tile.openstreetmap.org/16/21109/18966.png/dirty - reagardez
la tuile ;)


 En vous souhaitant un bon dimanche au soleil.


Croisons les doigts... d'ici une heure je serai sur la route des
vacances direction Carnac !
J'ai quelques adresses à vérifier là bas et quelques milliers de
menhirs à mapper ;)

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Josm : 2 instances ?

2013-07-21 Thread Hélène PETIT

Le 21/07/2013 08:47, Vincent de Château-Thierry a écrit :
 Yaka essayer ;-P
 Oui ça fonctionne, mais seule la première instance activera la
 telecommande (Remote Control): ce qui permet de jouer avec Osmose  co.

J'ai pas bien posé ma question ; la revoilà :
Chez moi**  un clic sur l'icône de josm ne relance pas une deuxième
instance de josm ; et vous, vous faites comment ?




Hélène
**
Identification: JOSM/1.5 (6060 fr) Windows 7 64-Bit
Memory Usage: 368 MB / 3640 MB (145 MB allocated, but free)
Java version: 1.7.0_17, Oracle Corporation, Java HotSpot(TM) 64-Bit
Server VM
VM arguments: [-Xmx4G]


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Josm : 2 instances ?

2013-07-21 Thread Christian Quest

Je pense que sous Windows, il faut que tu lance la deuxième instance
en ligne de commande (comme sous OSX, mais jamais essayé... au pire
j'ai 2 JOSM installés, un stable un dev)


Le 21 juillet 2013 08:56, Hélène PETIT h...@free.fr a écrit :
 Le 21/07/2013 08:47, Vincent de Château-Thierry a écrit :
 Yaka essayer ;-P
 Oui ça fonctionne, mais seule la première instance activera la
 telecommande (Remote Control): ce qui permet de jouer avec Osmose  co.

 J'ai pas bien posé ma question ; la revoilà :
 Chez moi**  un clic sur l'icône de josm ne relance pas une deuxième
 instance de josm ; et vous, vous faites comment ?




 Hélène
 **
 Identification: JOSM/1.5 (6060 fr) Windows 7 64-Bit
 Memory Usage: 368 MB / 3640 MB (145 MB allocated, but free)
 Java version: 1.7.0_17, Oracle Corporation, Java HotSpot(TM) 64-Bit
 Server VM
 VM arguments: [-Xmx4G]


 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Josm : 2 instances ?

2013-07-21 Thread Vincent de Château-Thierry



Le 21/07/2013 08:56, Hélène PETIT a écrit :


J'ai pas bien posé ma question ; la revoilà :
Chez moi**  un clic sur l'icône de josm ne relance pas une deuxième
instance de josm ; et vous, vous faites comment ?


Ah ? Ici je viens de tester en double-cliquant une fois puis deux sur le 
fichier .jar et ça marche (Windows 8 64 bits - Java 7) : j'ai 2 
instances à l'écran.

En temps normal je cliques sur un fichier .bat qui contient ça :
C:\Program Files\Java\jre7\bin\java.exe -jar -Xmx3000M josm-tested.jar
et à chaque clic une instance se lance. Enfin tant que la RAM suit :-)

vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Multi-polygone

2013-07-21 Thread mides.map





Ok, tout cela est bien noté ! 

Te souhaitant de bonnes vacances  ;-)

Christian Quest a écrit :

  Le 21 juillet 2013 08:29, mides.map mides@gmail.com a écrit :
  
  
Bonjour,

tout d'abord, merci pour tous ces conseils.

Concernant les frontières administratives, en général, j'évite de les
déplacer et si chevauchement de chemins, je privilégie les segments River,
highway, etc.

  
  

Dans le cas présent vu la copie d'écran, on dirait bien que la limite
administrative et le tracé de la rivière sont superposés.
C'est pour moi la pire solution... difficile de sélectionner l'un et
pas l'autre, lorsqu'on sélectionne la rivière on ne voit pas forcément
que les mêmes nœuds portent une limite administrative, etc, etc.


  
  
Pour ce qui est de la richesse du tracé : doit on alléger, dans la mesure du
raisonnable, ou faire au plus fin ?


  
  
Si tu as une source précise, autant être précis, non ?


  
  
Effectivement, il serait bon de rajouter quelques infos du style : lien
Wikipedia, navigabilité ou autres, mais je suppose que ces dernières doivent
être apportées sur le waterway:river et non pas waterway:riverbank.


  
  
Tout à fait. Le riverbank sert à avoir l'emprise du cours d'eau, le
filaire modélise lui la voie de communication, le sens d'écoulement,
etc.


  
  
Dans le cas d'un ilot, quel axe privilégier concernant le tracé du
waterway:river, je suppose qu'il ne peut y en avoir un de chaque cotés ?


  
  
Si bien sûr, il peut y en avoir un de chaque côté. Il peut même y
avoir un sens de circulation avec un oneway pour l'indiquer.


  
  
Et pour terminer, merci pour la syntaxe permettant de forcer le
rafraichissement des dalles, un me semble l'avoir déjà vu quelque part mais
il va de soi que l'avais oublié aussi. ;-)


  
  
Il faut récupérer l'adresse d'une tuile (clic droit), puis tu rajoute
/dirty à la fin de l'URL, exemple:
http://b.tile.openstreetmap.org/16/21109/18966.png/dirty - reagardez
la tuile ;)


  
  
En vous souhaitant un bon dimanche au soleil.


  
  
Croisons les doigts... d'ici une heure je serai sur la route des
vacances direction Carnac !
J'ai quelques adresses à vérifier là bas et quelques milliers de
menhirs à mapper ;)

  






___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rôtisserie ?

2013-07-21 Thread Vincent de Château-Thierry



Le 21/07/2013 08:11, Jean-Francois Nifenecker a écrit :

Le 20/07/2013 19:07, Philippe Verdy a écrit :

C'est une catégorie de boucherie, non ?

shop=butcher
butcher=poultry


poultry, c'est pour de la volaille, alors que pour moi les viandes que 
l'on trouve en rôtisserie sont parfois autres : des ribs par ex.

Pourquoi pas combiner avec cuisine=* ?
shop=butcher
cuisine=roast_meat (0 dans taginfo, mais il faut bien démarrer un jour...)


Certes cela n'indique pas que la volaille est vendue rôtie et non prête à
cuire. Mais bien peu de rôtisseries ne vendent que la volaille cuite, et la
plupart des endroits où on vend la volaille la proposent aussi rôtie.



Une rôtisserie est un commerce où l'on vend des poulets cuits (rôtis)
mais pas crus [1]. Donc, amha, les tags que tu proposes ne sont pas
adaptés, même si moi-même je n'ai pas d'idée.


[1] en général c'est l'inverse : quand tu as affaire avec un poulet,
c'est lui qui est cru et toi qui es cuit.


;-)

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rôtisserie ?

J avais bien compris mais je n'ai jamais vu une rôtisserie qui ne vendait
pas aussi ses poulets crus ! Bref sauf rare exception que je n'ai jamais
vues toutes les rôtisseries sont des volaillers aussi.  C'est plutôt la
situation inverse où des volaillers ne sont pas tous rôtisseurs tels que
ceux qui vendent des produits congelés et certains petits volaillers
itinérants sur les marchés et qu'on ne peut pas cartographier. Les autres
ont tous leurs rôtissoires.

 Message envoyé depuis un smartphone Android. Mes gros doigts sur un
panneau tactile trop petit et le clavier limité ou les corrections boguées
proposées rendent certaines corrections quasi infaisables. Ne tenez pas
compte des erreurs qui restent parce que la relecture est tout aussi
pénible dans l'espace qui reste!
Le 21 juil. 2013 08:12, Jean-Francois Nifenecker 
jean-francois.nifenec...@laposte.net a écrit :

 Le 20/07/2013 19:07, Philippe Verdy a écrit :
  C'est une catégorie de boucherie, non ?
 
  shop=butcher
  butcher=poultry
 
  Certes cela n'indique pas que la volaille est vendue rôtie et non prête à
  cuire. Mais bien peu de rôtisseries ne vendent que la volaille cuite, et
 la
  plupart des endroits où on vend la volaille la proposent aussi rôtie.
 

 Une rôtisserie est un commerce où l'on vend des poulets cuits (rôtis)
 mais pas crus [1]. Donc, amha, les tags que tu proposes ne sont pas
 adaptés, même si moi-même je n'ai pas d'idée.


 [1] en général c'est l'inverse : quand tu as affaire avec un poulet,
 c'est lui qui est cru et toi qui es cuit.
 --
 Jean-Francois Nifenecker, Bordeaux

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Josm : 2 instances ?

Même pas la peine car on peut aussi travailler sur deux calques séparés en
même temps dans la même instance et donc utiliser la télécommande et
fusionner les calques qu'on veut ou les voir superposés si on veut faire
des comparaisons.  L'intérêt de deux instances c'est pour travailler sur
deux régions séparées par exemple avec une en cours demandant encore du
travail et une autre pour un autre besoin plus urgent ou plus local

 Message envoyé depuis un smartphone Android. Mes gros doigts sur un
panneau tactile trop petit et le clavier limité ou les corrections boguées
proposées rendent certaines corrections quasi infaisables. Ne tenez pas
compte des erreurs qui restent parce que la relecture est tout aussi
pénible dans l'espace qui reste!
Le 21 juil. 2013 08:48, Vincent de Château-Thierry v...@laposte.net a
écrit :

 Bonjour,

 Le 21/07/2013 08:34, Jean-Francois Nifenecker a écrit :

 Le 21/07/2013 08:18, Hélène PETIT a écrit :

 Je ne sais pas s'il est possible de lancer deux instances de josm en
 même temps ?


 Yaka essayer ;-P

 Et, pour moi ça a l'air de marcher (Debian Weezy, Josm 5267, Java
 1.6.0.27). Bon, j'ai pas testé bien loin mais j'ai pu charger deux zones
 très différentes de France sans pb.

 Bon week-end au frais :)


 Oui ça fonctionne, mais seule la première instance activera la
 telecommande (Remote Control): ce qui permet de jouer avec Osmose  co.

 vincent

 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rôtisserie ?

Je confirme encore au arche de ce matin dont le stand marque rôtisserie
prépare aussi les poulets prêts à cuire mais pas nécessairement déjà cuits.
Effectivement il y a aussi des ribs et des brochettes et saucisses et
grillades mais tout ça vendu prêt à cuire, mais pas encore cuit.

Message envoyé depuis un smartphone Android. Mes gros doigts sur un
panneau tactile trop petit et le clavier limité ou les corrections boguées
proposées rendent certaines corrections quasi infaisables. Ne tenez pas
compte des erreurs qui restent parce que la relecture est tout aussi
pénible dans l'espace qui reste!
Le 21 juil. 2013 09:13, Vincent de Château-Thierry v...@laposte.net a
écrit :

Le 21/07/2013 08:11, Jean-Francois Nifenecker a écrit :

Le 20/07/2013 19:07, Philippe Verdy a écrit :

C'est une catégorie de boucherie, non ?

shop=butcher
butcher=poultry

poultry, c'est pour de la volaille, alors que pour moi les viandes que
l'on trouve en rôtisserie sont parfois autres : des ribs par ex.
Pourquoi pas combiner avec cuisine=* ?
shop=butcher
cuisine=roast_meat (0 dans taginfo, mais il faut bien démarrer un jour...)

Certes cela n'indique pas que la volaille est vendue rôtie et non prête à
cuire. Mais bien peu de rôtisseries ne vendent que la volaille cuite, et
la
plupart des endroits où on vend la volaille la proposent aussi rôtie.

Une rôtisserie est un commerce où l'on vend des poulets cuits (rôtis)
mais pas crus [1]. Donc, amha, les tags que tu proposes ne sont pas
adaptés, même si moi-même je n'ai pas d'idée.

[1] en général c'est l'inverse : quand tu as affaire avec un poulet,
c'est lui qui est cru et toi qui es cuit.

;-)

__**_
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Multi-polygone

Pour rafraîchir une métatuile bouton droit sur l'image pour l'afficher dans
un onglet séparé. Ensuite tu ajoutes à l URL:  /dirty
Après quelques minutes (c'est plus long pour les niveaux de zoom faibles)
tu purges ton cache navigateur et tu recharges la page pour avoir les
tuiles ou bien tu charges les tuiles une par une en forçant le
rafraîchissement avec Ctrl+R dans le navigateur...

Note que quand tu forces le serveur à rafraîchir une tuile en fait il en
recalcule une série autour (x et y dans l'URL multiples de 4 ou 8 selon les
moteurs de rendu, c'est à dire que la métatuile rafraîchie concernera 16 ou
64 tuiles téléchargées par ton navigateur).

 Message envoyé depuis un smartphone Android. Mes gros doigts sur un
panneau tactile trop petit et le clavier limité ou les corrections boguées
proposées rendent certaines corrections quasi infaisables. Ne tenez pas
compte des erreurs qui restent parce que la relecture est tout aussi
pénible dans l'espace qui reste!
Le 21 juil. 2013 08:30, mides.map mides@gmail.com a écrit :

 **
 Bonjour,

 tout d'abord, merci pour tous ces conseils.

 Concernant les frontières administratives, en général, j'évite de les
 déplacer et si chevauchement de chemins, je privilégie les segments River,
 highway, etc.

 Pour ce qui est de la richesse du tracé : doit on alléger, dans la mesure
 du raisonnable, ou faire au plus fin ?

 Effectivement, il serait bon de rajouter quelques infos du style : lien
 Wikipedia, navigabilité ou autres, mais je suppose que ces dernières
 doivent être apportées sur le waterway:river et non pas waterway:riverbank.

 Dans le cas d'un ilot, quel axe privilégier concernant le tracé du
 waterway:river, je suppose qu'il ne peut y en avoir un de chaque cotés ?

 Et pour terminer, merci pour la syntaxe permettant de forcer le
 rafraichissement des dalles, un me semble l'avoir déjà vu quelque part mais
 il va de soi que l'avais oublié aussi. ;-)

 En vous souhaitant un bon dimanche au soleil.

 Michel

 hamster a écrit :

 Le 21/07/2013 00:39, Yves Pratter a écrit :


  La difficultés ici c'est que les frontières administratives suivent
 cette ligne. Il faut soit accepter de les déplacer ??



 oh non, certainement pas



  soit faire deux
 chemins distincts, un pour la rivière, un autre pour les frontières.



 c'est bien mieux comme ca oui

 ___
 Talk-fr mailing 
 listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr
 .





 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Multi-polygone

2013-07-21 Thread mides.map





Merci pour ces explications.

Philippe Verdy a crit:

  Pour rafrachir une mtatuile bouton droit sur l'image
pour l'afficher dans un onglet spar. Ensuite tu ajoutes  l URL:
/dirty
Aprs quelques minutes (c'est plus long pour les niveaux de zoom
faibles) tu purges ton cache navigateur et tu recharges la page pour
avoir les tuiles ou bien tu charges les tuiles une par une en forant
le rafrachissement avec Ctrl+R dans le navigateur...
  Note que quand tu forces le serveur  rafrachir une
tuile en fait il en recalcule une srie autour (x et y dans l'URL
multiples de 4 ou 8 selon les moteurs de rendu, c'est  dire que la
mtatuile rafrachie concernera 16 ou 64 tuiles tlcharges par ton
navigateur). 
   Message envoy depuis un smartphone Android. Mes
gros doigts sur un panneau tactile trop petit et le clavier limit ou
les corrections bogues proposes rendent certaines corrections quasi
infaisables. Ne tenez pas compte des erreurs qui restent parce que la
relecture est tout aussi pnible dans l'espace qui reste!
  Le 21 juil. 2013 08:30, "mides.map" mides@gmail.com
a crit:
  

Bonjour, 

tout d'abord, merci pour tous ces conseils.

Concernant les frontires administratives, en gnral, j'vite de les
dplacer et si chevauchement de chemins, je privilgie les segments
River, highway, etc.

Pour ce qui est de la richesse du trac : doit on allger, dans la
mesure du raisonnable, ou faire au plus fin ? 

Effectivement, il serait bon de rajouter quelques infos du style : lien
Wikipedia, navigabilit ou autres, mais je suppose que ces dernires
doivent tre apportes sur le waterway:river et non pas
waterway:riverbank.

Dans le cas d'un ilot, quel axe privilgier concernant le trac du
waterway:river, je suppose qu'il ne peut y en avoir un de chaque cots ?

Et pour terminer, merci pour la syntaxe permettant de forcer le
rafraichissement des dalles, un me semble l'avoir dj vu quelque part
mais il va de soi que l'avais oubli aussi. ;-)

En vous souhaitant un bon dimanche au soleil.

Michel

hamster a crit:

  Le 21/07/2013 00:39, Yves Pratter a crit :
  
  
La difficults ici c'est que les frontires administratives suivent
cette ligne. Il faut soit accepter de les dplacer ??

  
  oh non, certainement pas

  
  
soit faire deux
chemins distincts, un pour la rivire, un autre pour les frontires.

  
  c'est bien mieux comme ca oui

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
.

  




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

  
  
  

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
  






___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rôtisserie ?

2013-07-21 Thread Pieren

2013/7/21 Vincent de Château-Thierry v...@laposte.net:

 Pourquoi pas combiner avec cuisine=* ?
 shop=butcher
 cuisine=roast_meat (0 dans taginfo, mais il faut bien démarrer un jour...)

Je garderais butcher pour les bouchers. Quand je regarde un
dictionnaire, je vois que les anglais, dans leur immense sagesse,
traduisent rôtisserie par rotisserie (notez la disparition du
petit chapeau, peut-être un marqueur trop visible de l'influence
française sur la langue de Shakespeare ;-)
Si ça n'est pas vraiment un restaurant, ni un fast-food, ni un
traiteur, ni un boucher, alors pourquoi pas amenity=rotisserie ? Si
c'est vraiment un restaurant qui fait aussi rôtisserie, alors ajouter
un cuisine=rotisserie ou rotisserie=yes. Même chose pour
fast_food, etc (à mettre dans le wiki ?)

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] umap

2013-07-21 Thread Vincent Pottier


Bonsoir,

En me baladant sur le web [1], je suis tombé sur un concurrent de umap [2].
Je me dis :
* qu'il y a de l'avenir pour umap
* qu'on a encore du boulot pour arriver à ce niveau de proposition.
* qu'OSM et son écosystème propose une foultitude de fond de carte, ce 
que d'autre ne peuvent proposer...
* qu'il n'y a plus grand chose en nom de domaine disponible en umap pour 
le faire exister comme tel (comme maposmatic). Vérifié sur gandi.net
* que lorsque umap aura pris un peu plus de développement, on pourra 
facilement le proposer comme alternative, par exemple à tela-botanica, 
et qu'un écosystème se développera autour de umap.

* que la route est longue mais que la voie est libre...

[1] http://www.tela-botanica.org/actu/article5534.html
[2] http://www.zeemaps.com
--
FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[Talk-us] JOSM MacOS fail

2013-07-21 Thread Dion Dock

Has anyone noticed that holding Option+click no longer scrolls the window?  I 
filed a defect which was downgraded and duplicated and still is open. It 
basically breaks my workflow.  Does anyone know which old version works?

Dion


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] tile.openstreetmap.us down tomorrow

I need to bring the configurations for the vector datasets up to date, now that 
the Postgres tables are all back.

http://openstreetmap.us/~migurski/vector-datasource/

-mike.

On Jul 20, 2013, at 4:28 PM, Ian Dees wrote:

 Hi all,
 
 After some confusion about getting our new memory working, we should be back 
 to normal now.
 
 Most of the tile.openstreetmap.us layers are working again (including the 
 USGS Large Scale and TIGER 2012 Roads layer).
 
 Let me know if you see otherwise.
 -Ian
 
 
 On Wed, Jul 17, 2013 at 3:43 PM, Ian Dees ian.d...@gmail.com wrote:
 Yep, there was a hiccup when the data center folks restored the 500GB 
 Postgres partition onto the 20GB root partition, so it's happening again.
 
 We should get it back up this evening.
 
 
 On Wed, Jul 17, 2013 at 3:35 PM, Ben Miller bborkmil...@gmail.com wrote:
 Is the hardware upgrade still in progress? I'm not seeing the TIGER or USGS 
 topo layers currently.
 
 Thanks for the upgrades, BTW, whatever they may be!
 
 
 On Mon, Jul 15, 2013 at 10:07 AM, Ian Dees ian.d...@gmail.com wrote:
 This downtime didn't happen last week. I expect that it will happen today and 
 hopefully be back up by some time tomorrow.
 
 
 On Thu, Jul 11, 2013 at 7:47 PM, Ian Dees ian.d...@gmail.com wrote:
 Hi folks,
 
 We're installing some hardware upgrades in the server running 
 tile.openstreetmap.us, so some of the tile layers in the editors will be 
 unavailable for the day.
 
 The layers that might not work:
 - TIGER 2012 Road Names
 - USGS Topo Maps
 - USGS Large Scale Aerials
 - some other layers that are used less frequently
 
 Please let me know if you have any questions,
 Ian
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us
 
 
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html





___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] JOSM MacOS fail

2013-07-21 Thread Ian Dees

Do you mean Control+Drag to scroll the window? I've seen control+drag doing
weird things in the last month or so but option+drag has never really done
anything specific.


On Sun, Jul 21, 2013 at 12:10 PM, Dion Dock dion_d...@comcast.net wrote:

 Has anyone noticed that holding Option+click no longer scrolls the window?
  I filed a defect which was downgraded and duplicated and still is open. It
 basically breaks my workflow.  Does anyone know which old version works?

 Dion


 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Steady increase in the number of mappers in the US